16주차
이번주는... 코딩테스트 문제를 풀었다. 28시간정도 40문제 가량. 가장 어려운 문제라고 해도 프로그래머스 사이트에서는 레벨 1정도인 문제였고 재미있게 풀었으나 조금은 아쉬운 순간이다. 천천히 레벨을 높여가면서 해결해봐야겠다.
코딩테스트 문제의 기본을 풀어가면서, 자바스크립트 문법과 실행 컨텍스트에 대해서 조금 더 잘 이해할 수 있었던 것이 이번주의 수확이었다.
가장 기본이 되는 객체, 배열, 문자열, 함수 등을 활용해서 머리로 생각한 논리를 구현하는 연습을 했다. 특히 보기만해도 읽기 귀찮아 했던 재귀함수라던가, map, filter, reduce 메서드 사용 방법에 대해서 조금은 체득할 수 있었다. 각 메서드를 많이 써보고 나니, 일종의 python의 list나 dictionary comprehension과 닮은점이 있다는 생각이 들었다.
그래도 나름 어떤 방식으로 구현하는 것이 메모리 사용을 적게 하고, 계산속도를 더 빠르게 하는 것인지에 대해서 고민하면서 구현하기도 하고, 더 복잡하지만 적은 코드 혹은 간단한 로직이지만 더 긴 코드로 구현해보기도 하는 등 푼 문제수를 늘리기 위한 풀이는 하지 않았다는 점에서 잘 보낸 한 주라고 생각한다.
그리고 다음 주차에 배울 내용에 대해 미리 살펴보는 차원으로,
- Express 미들웨어
- RESTful
두가지에 대해서 검색하며 정리해본다. 새로운 정보를 검색할 때의 공식은 이제 chatGPT가 바이럴 해진 이후 달라졌다. 특히 개발 관련 정보는 통계적앵무새의 할루시네이션을 고민할 이유가 거의 없는 활용도 높은 도구가 되었다. 공부하는 입장에서 코드를 쓰라는 요구만 하지 않는 선에서 궁금한 것에 대한 1차 정보를 얻는 도구로서 아주 유용하다. 좋은 질문으로 시간을 단축하자. 이번에도 검색 전에 기본적인 정보를 얻고 질문을 이어보면,
1. Express 미들웨어
나: Express 미들웨어
chatGPT: Express 미들웨어는 Node.js의 웹 프레임워크인 Express에서 HTTP 요청을 처리하는 도중에 중간에 실행되는 함수입니다. 미들웨어는 요청과 응답 객체 그리고 다음 미들웨어 함수로 연결된 콜백 함수를 인자로 받아 실행됩니다.
미들웨어는 다음과 같은 일을 수행할 수 있습니다:
1. 요청 객체(req)와 응답 객체(res)의 프로퍼티를 변경하거나 추가할 수 있습니다.
2. 다음 미들웨어 함수로 요청을 전달할지 여부를 결정할 수 있습니다.
3. 요청을 처리한 후에 다른 미들웨어 함수를 호출할 수 있습니다.
Express 미들웨어는 다양한 기능을 수행할 수 있습니다. 예를 들어, 로깅, 인증, 세션 관리, 파일 업로드 등의 기능을 구현할 수 있습니다. 또한, Express 미들웨어는 다른 npm 패키지를 사용하여 추가 기능을 구현할 수도 있습니다.
읽고나니, 대략의 역할은 이해했다. HTTP의 요청과 응답을 서버와 클라이언트 중간에서 처리해주기 때문에 미들웨어로 부르는 것인지 궁금해서,
나: 받는 요청과 보낼 응답을 쉽게 다루는 방법을 Express 프레임워크에서 제공한다고 이해하면 맞을까?
chatGPT: 맞습니다. Express 프레임워크는 Node.js의 기본 HTTP 모듈을 기반으로 하며, HTTP 요청과 응답 객체를 더 쉽게 다룰 수 있는 방법을 제공합니다.
Express에서는 라우팅(Routing)을 사용하여 HTTP 요청을 적절한 핸들러 함수로 라우팅합니다. 이를 통해 어떤 URL에 대한 요청이 들어왔을 때, 어떤 로직을 실행할지 결정할 수 있습니다.
또한, Express에서는 미들웨어(Middleware)를 사용하여 HTTP 요청과 응답을 처리합니다. 미들웨어는 요청과 응답 객체를 가로채서 원하는 작업을 수행하고, 다음 미들웨어나 핸들러 함수로 요청을 전달합니다. 이를 통해 HTTP 요청과 응답 객체를 더 쉽게 다룰 수 있습니다.
Express에서는 또한 다양한 뷰(View) 엔진을 지원하여 HTML, XML, JSON 등 다양한 형식의 응답을 처리할 수 있습니다. 이를 통해 클라이언트에게 필요한 데이터를 쉽게 전달할 수 있습니다.
뷰 엔진에 대해서는 더 깊게 물어보고 싶었지만 곁다리로 빠질 것 같아서, 실제 예시가 궁금해서 물어봤다.
나: 간단한 hello world를 표시하고 메세지를 post하는 웹페이지를 가정했을 때, express 쓰는 경우와 안쓰는 경우의 차이를 가지고 조금 더 자세히 설명해줘
chatGPT: 간단한 "Hello, World!"를 표시하고 메시지를 POST하는 웹 페이지를 구현한다면, Express를 사용하는 경우와 사용하지 않는 경우의 차이는 다음과 같습니다.
Express를 사용하는 경우:
1. Express 프레임워크를 사용하여 서버를 구현합니다.
2. app.get() 메서드를 사용하여 GET 요청을 처리하고, res.send() 메서드를 사용하여 "Hello, World!"를 클라이언트에게 전송합니다.
3. app.post() 메서드를 사용하여 POST 요청을 처리하고, req.body 객체를 사용하여 클라이언트가 전송한 메시지를 읽어들입니다.
const express = require('express'); const app = express(); app.get('/', (req, res) => { res.send('Hello, World!'); }); app.post('/message', (req, res) => { const message = req.body.message; console.log('Received message:', message); res.send('Message received!'); }); app.listen(3000, () => { console.log('Server listening on port 3000'); });
Express를 사용하지 않는 경우:
Node.js의 기본 HTTP 모듈을 사용하여 서버를 구현합니다.
http.createServer() 메서드를 사용하여 서버를 생성하고, res.write() 및 res.end() 메서드를 사용하여 "Hello, World!"를 클라이언트에게 전송합니다.
req.on('data', callback) 이벤트를 사용하여 POST 요청의 데이터를 수신하고, Buffer.concat() 메서드를 사용하여 데이터를 결합합니다.const http = require('http'); const qs = require('querystring'); const server = http.createServer((req, res) => { if (req.method === 'GET' && req.url === '/') { res.writeHead(200, { 'Content-Type': 'text/plain' }); res.write('Hello, World!'); res.end(); } else if (req.method === 'POST' && req.url === '/message') { let body = []; req.on('data', chunk => { body.push(chunk); }).on('end', () => { body = Buffer.concat(body).toString(); const message = qs.parse(body).message; console.log('Received message:', message); res.writeHead(200, { 'Content-Type': 'text/plain' }); res.write('Message received!'); res.end(); }); } else { res.writeHead(404, { 'Content-Type': 'text/plain' }); res.write('404 Not Found'); res.end(); } }); server.listen(3000, () => { console.log('Server listening on port 3000'); });
Express를 사용하지 않으면, HTTP 요청과 응답 객체를 직접 다루어야 하므로 코드가 더 복잡해집니다. 또한, Express를 사용하지 않으면 라우팅(Routing)과 미들웨어(Middleware) 기능을 따로 구현해야 하므로 코드의 재사용성이 떨어질 수 있습니다. 따라서 Express를 사용하면 코드의 간결성과 유지보수가 쉬워지며, 빠르게 웹 어플리케이션을 개발할 수 있습니다. Express는 매우 간단하고 직관적인 API를 제공하며, 라우팅 및 미들웨어 기능을 지원하여 코드를 구성하고 구조화하는 것이 훨씬 쉬워집니다.
Express를 쓰지 않은 경우와 비교하니 대강의 역할과 편리성을 이해할 수 있을 것 같다. 요청 방법과 url에 대해 if문으로 구분하고, 응답 코드와 메세지를 일일이 다 담아서 보내고, 404도 따로 예외처리 해줘야 하는 등의 복잡한 구현을 Express를 사용할 경우 간단하게 구현할 수 있어 보인다.
2. RESTful
RESTful에 대해서는 종종 봤던 것 같은데 정확하게 어떤의미인지는 여전히 몰랐다.
나: RESTful에 대해 설명해줘
chatGPT: REST는 Representational State Transfer의 약어로, 웹 서비스를 설계하고 구현하는 데 사용되는 아키텍처 스타일입니다. RESTful은 이 아키텍처 스타일을 따르는 웹 서비스를 말합니다.
RESTful 웹 서비스는 다양한 클라이언트와 통신할 수 있으며, 클라이언트는 HTTP 메서드 (GET, POST, PUT, DELETE 등)를 사용하여 서버에 요청을 보낼 수 있습니다. 서버는 이러한 요청을 받아들이고, 자원을 나타내는 URL을 사용하여 해당 자원에 대한 작업을 수행합니다.
RESTful 웹 서비스는 다음과 같은 특징을 갖습니다.
1. 클라이언트-서버 구조: 클라이언트와 서버가 독립적으로 개발되고 유지보수될 수 있습니다.
2. 상태 없음: 서버는 클라이언트의 상태를 유지하지 않으며, 각각의 요청은 독립적입니다.
3. 캐시 가능: 클라이언트는 응답을 캐시할 수 있습니다.
4. 계층화: 서버는 계층화될 수 있으며, 로드 밸런싱, 보안, 공유 캐시 등의 기능을 추가할 수 있습니다.
5. 인터페이스 일관성: 자원에 대한 작업은 표준화된 HTTP 메서드를 사용하여 일관성을 유지합니다.
RESTful 웹 서비스는 다양한 클라이언트와 서버 간의 상호 작용을 촉진하며, 웹 서비스를 개발하고 배포하는 데 유용합니다.
각각에 대해 아주 모르겠진 않지만, 조금 더 알고 싶어 RESTful하지 않은 경우 RESTful 웹 서비스 특징이 어떻게 달라지는지 물어봤다.
나: RESTful하지 않은 경우 RESTful 웹 서비스 특징이 어떻게 달라질까?
chatGPT: RESTful하지 않은 경우, 일관성과 유연성이 떨어지고, 클라이언트와 서버 간의 상호 작용이 제한됩니다. 예를 들어, RESTful하지 않은 웹 서비스에서는 URL을 통해 자원에 접근할 수 없거나, HTTP 메서드를 사용하지 않고, 상태를 유지하는 등의 특징이 나타날 수 있습니다. 이 경우, 다음과 같은 차이점이 있습니다.
1. 클라이언트-서버 구조: RESTful하지 않은 경우, 클라이언트와 서버 간에 역할이 명확하게 분리되지 않을 수 있습니다. 이로 인해, 클라이언트와 서버의 독립적인 개발 및 유지보수가 어려워질 수 있습니다.
2. 상태 유지: RESTful하지 않은 경우, 서버가 클라이언트의 상태를 유지할 수 있습니다. 이로 인해, 클라이언트와 서버 간의 상호작용이 단순해지지만, 상태 유지로 인한 보안 문제나 확장성 문제가 발생할 수 있습니다.
3. 캐시 불가능: RESTful하지 않은 경우, 클라이언트가 응답을 캐시할 수 없으며, 매번 요청할 때마다 서버에서 데이터를 가져와야 합니다.계층화 제한: RESTful하지 않은 경우, 서버의 계층화가 제한될 수 있습니다. 예를 들어, 로드 밸런싱, 보안, 공유 캐시 등의 기능을 추가하기 어려울 수 있습니다.인터페이스
4. 일관성: RESTful하지 않은 경우, HTTP 메서드를 사용하지 않거나, 자원에 대한 작업이 일관적이지 않을 수 있습니다.
따라서 RESTful하지 않은 웹 서비스는 유연성이 떨어지고, 확장성이 떨어지며, 다양한 클라이언트와 상호 작용하기 어려울 수 있습니다.
나: 그럼 RESTful하지 않은 웹 서비스의 장점은?
chatGPT: RESTful하지 않은 웹 서비스의 장점은 몇 가지 있을 수 있습니다.
1. 상태 유지: RESTful하지 않은 웹 서비스에서는 서버가 클라이언트의 상태를 유지할 수 있습니다. 이를 통해, 세션 관리나 보안 문제를 해결할 수 있습니다.
2. 메서드 확장성: RESTful하지 않은 웹 서비스에서는 HTTP 메서드를 사용하지 않는 것이 아닌, 자체적으로 정의한 메서드를 사용할 수 있습니다. 이를 통해, 자원에 대한 다양한 작업을 수행할 수 있습니다.
3. 속도: RESTful하지 않은 웹 서비스에서는 서버에 대한 HTTP 요청과 응답의 수를 줄일 수 있습니다. 이를 통해, 데이터 전송 속도를 향상시킬 수 있습니다.
4. 구현 용이성: RESTful하지 않은 웹 서비스에서는 RESTful 웹 서비스와 달리, 일부 기능을 구현하는 데 더 적은 노력이 필요할 수 있습니다.
그러나 이러한 장점들은 RESTful 웹 서비스의 장점에 비해 상대적으로 적은 수준의 이점들입니다. 또한, RESTful하지 않은 웹 서비스는 다양한 클라이언트와의 상호 작용이 제한될 수 있고, 확장성이 제한될 수 있으므로, 적절한 경우에만 사용하는 것이 좋습니다.
url에 요청의 의미를 내포하는 단순한 구성으로 한다는 설명을 들은 것 같아서 물어봤다.
나: url을 사용하는 방식으로 RESTful에 대해 설명하던데 어떤 이유일까?
chatGPT: RESTful 아키텍처에서는 URL을 사용하여 자원을 나타내고, HTTP 메서드를 사용하여 자원에 대한 작업을 수행합니다. 이러한 방식을 사용하는 이유는 다음과 같습니다.
1. 자원 식별: URL을 사용하여 자원을 식별할 수 있습니다. 예를 들어, /users/{id}와 같은 URL을 사용하여 특정 사용자를 식별할 수 있습니다.
2. 인터페이스 일관성: RESTful 아키텍처에서는 HTTP 메서드를 사용하여 자원에 대한 작업을 수행합니다. 이러한 인터페이스 일관성을 유지하는 것은 클라이언트와 서버 간의 상호 운용성을 향상시키고, 코드의 가독성과 이해성을 향상시킵니다.
3. 캐시: URL을 사용하여 자원을 식별하면, 클라이언트가 서버에서 응답을 캐시할 수 있습니다. 이를 통해, 클라이언트의 요청 횟수를 줄이고, 데이터 전송 속도를 향상시킬 수 있습니다.
4. 로드 밸런싱: URL을 사용하여 자원을 식별하면, 서버는 로드 밸런싱과 같은 기능을 추가할 수 있습니다. 예를 들어, /users/{id}와 같은 URL에서 {id}를 기반으로 서버를 분산시킬 수 있습니다.
5. 유연성: URL을 사용하여 자원을 식별하면, 자원의 위치와 구조를 변경할 수 있습니다. 이를 통해, API의 유연성과 확장성을 향상시킬 수 있습니다.
따라서, URL을 사용하는 방식은 RESTful 아키텍처에서 중요한 역할을 합니다. URL을 사용하여 자원을 식별하고, HTTP 메서드를 사용하여 자원에 대한 작업을 수행함으로써, RESTful 아키텍처는 클라이언트와 서버 간의 상호 운용성을 향상시키고, 유연성과 확장성을 제공합니다.
이번에도 RESTful과 아닌 것의 간단한 웹페이지를 기준으로 설명해달라고 요청했다.
나: 단순한 웹 서비스 기준으로 RESTful한 구조와 아닌 구조에 대한 비교로 설명해준다면?
chatGPT: 단순한 웹 서비스를 예로 들어 설명하겠습니다. 예를 들어, 사용자 이름을 입력하면 해당 사용자의 나이를 반환하는 웹 서비스를 가정해보겠습니다.
RESTful한 구조
RESTful한 구조에서는 다음과 같은 방식으로 웹 서비스를 구현할 수 있습니다.
1. URL: /users/{username}/age와 같은 URL을 사용하여 자원을 표현합니다. 이 경우, {username}은 사용자 이름으로 대체됩니다.
2. HTTP 메서드: GET 메서드를 사용하여 자원의 상태(해당 사용자의 나이)를 반환합니다.
3. 메시지: HTTP 응답 메시지는 자기 표현적(self-descriptive)이어야 합니다. 즉, 응답 메시지는 해당 자원의 상태와 함께 클라이언트 측에서 이해할 수 있는 정보를 제공해야 합니다.
따라서, RESTful한 구조에서는 다음과 같은 방식으로 웹 서비스를 구현할 수 있습니다.
RESTful하지 않은 구조
RESTful하지 않은 구조에서는 다음과 같은 방식으로 웹 서비스를 구현할 수 있습니다.
1. URL: /get_age.php와 같은 URL을 사용하여 자원을 표현합니다. 이 경우, 사용자 이름은 HTTP 요청 본문에서 전달됩니다.
2. HTTP 메서드: POST 메서드를 사용하여 자원의 상태(해당 사용자의 나이)를 반환합니다.
3. 메시지: HTTP 응답 메시지는 자기 표현적(self-descriptive)이 아닐 수 있습니다. 즉, 클라이언트는 서버의 도움을 받아 응답 메시지를 이해해야 합니다.
따라서, RESTful하지 않은 구조에서는 다음과 같은 방식으로 웹 서비스를 구현할 수 있습니다.
알듯말듯, 조금 더 다른사람들이 쓴 글을 읽어봐야겠다.
'daily' 카테고리의 다른 글
23.04.24. node.js, express, mongoose, mongoDB 관계, 구조 (0) | 2023.04.25 |
---|---|
23.04.19. programmers 코딩테스트 문제 풀기[6] (0) | 2023.04.20 |
23.04.17. programmers 코딩테스트 문제 풀기[5] (0) | 2023.04.20 |
23.04.17. programmers 코딩테스트 문제 풀기[4] (0) | 2023.04.20 |
23.04.17. for...in, for...of (0) | 2023.04.17 |