clone toy projects 썸네일형 리스트형 ws 모듈로 웹소켓 사용하기 git-chat라는 폴더 생성 후 기본 패키지 구성 app.js routes/index.js npm install ws 웹 소켓을 익스트프레스 서버와 연결. 웹 소켓 로직이 들어있는 socket.js 파일 작성 ws 모듈을 불러온 후 익스프레스 서버를 웹소켓 서버와 연결했습니다. 익스프레스(HTTP)와 웹소켓(WS)은 같은 포트를 공유할 수 있어 별도의 작업이 필요하지 않습니다. 연결 후에는 웹소켓 서버(wss)에 이벤트 리스너를 붙입니다. 웹소켓은 이벤트 기반으로 작동한다고 생각하면 됩니다. 실시간으로 데이터를 전달받으므로 항상 대기하고 있어야 합니다. "connection" 이벤트는 클라이언트가 서버와 웹소켓 연결을 맺을 때 발생합니다. req.headers['x-forwarded-for']와 req.. 더보기 웹소켓 이해하기 '노드의 교과서'를 토대로 진행 노드 생태계에서는 "웹소켓"이라는 말을 들으면 보통 먼저 "Socket.IO"를 떠올리는 경우가 많습니다. 하지만 Socket.IO는 웹소켓을 활용한 라이브러리일 뿐이며, 웹소켓 그 자체는 아닙니다. 나중에 Socket.IO를 사용하기 위해서는 기반 기술인 웹소켓에 대해 먼저 알아야 합니다. 웹소켓은 HTML5에 새로 추가된 스펙으로, 실시간 양방향 데이터 전송을 위한 기술입니다. 이 기술은 HTTP와 다르게 WS라는 프로토콜을 사용합니다. 따라서 브라우저와 서버가 WS 프로토콜을 지원하면 사용할 수 있습니다. 노드(Node.js) 환경에서는 ws나 Socket.IO 같은 패키지를 통해 웹소켓을 사용할 수 있습니다. 웹소켓이 나오기 이전에는 HTTP 기술을 사용하여 실시간.. 더보기 부하 테스트 이번 절에서는 다른 종류의 테스트를 진행해보겠습니다. 바로 부하 테스트 (loadtest)입니다. 서버가 얼마만큼의 요청을 견딜 수 있는지 (또는 수용할 수 있는지) 테스트하는 방법입니다. 내 코드가 실제로 배포되었을 때 어떤 문법적, 논리적 문제가 있을지는 유닛 테스트와 통합 테스트를 통해 어느 정도 확인할 수 있습니다. 그러나 내 서버가 몇 명의 동시 접속자나 일일 사용자를 수용할 수 있는지 예측하는 일은 매우 어렵습니다. 특히 실제 서비스 중이 아니라 개발 중일 때는 예측하는 것이 더 어려워집니다. 코드에 문법적, 논리적 문제가 없더라도 서버의 하드웨어 제약 때문에 비즈니스가 중단될 수 있습니다. 대표적인 예가 "OOM (Out of Memory)" 문제입니다. 서버는 접속자들의 정보를 저장하기 위.. 더보기 통합 테스트 이번 절에서는 하나의 라우터를 통째로 테스트해볼 것입니다. "routes" 폴더에 "auth.test.js"를 작성합니다. 하나의 라우터에는 여러 개의 미들웨어가 붙어있고, 다양한 라이브러리가 사용됩니다. 이런 것들이 모두 유기적으로 잘 작동하는지 테스트하는 것이 통합 테스트 (integration test)입니다. npm install -D supertest Supertest 패키지를 사용해 auth 라우터들을 테스트할 것입니다. Supertest를 사용하기 위해서는 app 객체를 모듈로 만들어 분리해야 합니다. "app.js" 파일에서 app 객체를 모듈로 만든 후, "server.js"에서 불러와 Listen합니다. "server.js"는 app의 포트 리스닝만 담당합니다. npm start 명령어.. 더보기 테스트 커버리지 유닛 테스트를 작성하다 보면, 전체 코드 중에서 어떤 부분이 테스트되고 어떤 부분이 테스트되지 않는지 궁금해집니다. 어떤 부분이 테스트되지 않는지를 알아내어 해당 부분의 테스트 코드를 작성할 수 있습니다. 전체 코드 중에서 테스트되고 있는 코드의 비율과 테스트되고 있지 않은 코드의 위치를 알려주는 Jest의 기능이 있습니다. 이 기능은 커버리지(coverage) 기능입니다. 테스트 결과가 출력되고, 추가적으로 표가 하나 더 출력됩니다. 표의 열을 살펴보면, 각각 File (파일과 폴더 이름), % Stmts (구문 비율), % Branches (if문 등의 분기점 비율), % Funcs (함수 비율), % Lines (코드 줄 수 비율), Uncovered Line #s (커버되지 않은 줄 위치)입니다... 더보기 유닛 테스트 middlewares.js에 있는 isLoggedIn과 isNotLoggedIn 함수를 테스트해보겠습니다. isLoggedIn 함수와 isNotLoggedIn 함수를 불러와 네 개의 테스트를 작성했습니다. 아직 내용은 입력하지 않았습니다. describe 함수는 처음 보는 것일텐데요. 이 함수는 테스트를 그룹화해주는 역할을 합니다. test 함수와 마찬가지로 첫 번째 인수는 그룹에 대한 설명이고, 두 번째 인수인 함수는 그룹에 대한 내용입니다. 테스트 내용을 작성하기에 앞서 middlewares.is를 다시 보고 오겠습니다 실제 코드에서는 익스프레스가 req, res 객체와 next 함수를 인수로 넣었기에 사용할 수 있었지만, 테스트 환경에서는 어떻게 넣어야 할지 고민됩니다. req 객체에는 isAuth.. 더보기 테스트 준비하기 이번 장에서는 NodeBird 서비스에 테스팅을 적용해보겠습니다. 실제 서비스를 개발 완료한 후, 개발자나 QA들은 자신이 만든 서비스가 제대로 동작하는지 테스트해봅니다. 이 때 기능이 많다면 일일이 수작업으로 테스트하기에는 작업량이 너무 많을 수 있습니다. 이런 경우 테스트를 자동화하여 프로그램이 프로그램을 테스트하도록 만들기도 합니다. 또한, 테스트 환경과 실제 서비스 환경은 다르므로 테스트하는 데 제약이 따를 수도 있고, 테스트 결과와 실제 동작 결과가 다를 수도 있습니다. 이럴 때는 테스트 환경에서 실제 환경을 최대한 흉내내서 작업합니다. 단, 테스트를 아무리 철저하게 해도 모든 에러를 완전히 막을 수는 없습니다. 보통 에러는 개발자가 예상하지 못 한 케이스에서 발생하므로, 예상하지 못한다면 그에.. 더보기 CORS 이해하기 이전 절에서 NodeCat이 nodebird-api를 호출하는 것은 서버에서 서버로 API를 호출한 것입니다. 만약 NodeCat의 프론트에서 nodebird-api의 서버 API를 호출하면 어떻게 될까요? routes/index.js에 프론트 화면을 렌더링하는 라우터를 추가합니다. 프론트 화면도 추가 clientSecret의 {{key}} 부분이 Nunjucks에 의해 실제 키로 치환되어 렌더링됩니다. 단, 실제 서비스에서는 서버에서 사용하는 비밀 키와 프론트에서 사용하는 비밀 키를 따로 두는 것이 좋습니다. 보통 서버에서 사용하는 비밀 키가 더 강력하기 때문입니다. 프론트에서 사용하는 비밀 키는 모든 사람에게 노출된다는 단점도 따릅니다. 데이터베이스에서 clientSecret 외에 frontSecre.. 더보기 이전 1 2 3 4 5 6 7 8 다음
