node

부하 테스트 서버가 얼마만큼의 요청을 견딜 수 있는지 테스트를 해보자. 코드에 문법적, 논리적 문제가 없더라도 서버의 하드웨어 제약 때문에 서비스가 중단될 수 있다. 대표적인 경우가 OOM(Out of Memory)이다. 서버는 접속자들의 정보를 저장하기 위해 각각의 접속자마다 일정한 메모리를 할당한다. 이렇게 사용하는 메모리의 양이 증가하다가 서버의 메모리 용량을 넘어서게 되면 문제가 발생한다. artillery를 설치하고 서버를 실행해보자. npm i -D artillery npm start 그리고 터미널을 하나 더 실행시켜 다음 명령어를 이용하여 100명의 가상 사용자가 50번씩 요청을 보내게 해보자. npx artillery quick --count 100 -n 50 http://localhost..

통합 테스트 라우터를 통째로 테스트해보자. routes 폴더에 auth.test.js를 작성하자. 하나의 라우터에는 여러 개의 미들웨어가 붙어 있고, 다양한 라이브러리가 사용된다. 이런 것들이 모두 유기적으로 잘 작동하는지 테스트하는 것이 통합 테스트이다. supertest를 설치하자. npm i -D supertest supertest를 사용해 auth.js를 테스트할 것이다. supertest를 사용하기 위해서는 app 객체를 모듈로 만들어 분리해야 한다. const express = require('express'); const cookieParser = require('cookie-parser'); const morgan = require('morgan'); const path = require(..

테스트 커버리지 유닛 테스트를 진행하다 보면 어떤 부분이 테스트되고 어떤 부분이 테스트되지 않는지 궁금할 수 있다. jest의 기능중에 전체 코드 중에 테스트되고 있는 코드의 비율과 테스트되고 있지 않은 코드의 위치를 알려주는 jest의 기능이 있다. 이를 커버리지(coverage) 라고한다. "scripts": { "start": "nodemon app", "test": "jest", "coverage": "jest --coverage" }, 스크립트를 작성하자. 그리고 실행해보자. npm run coverage File은 파일, 폴더 이름, %Stmts는 구문 비율, %Branch는 if문 등의 분기점 비율, %Funcs는 함수 비율, %Lines는 코드 비율, Uncovered Line #s는 커버..

테스트 준비 NodeBird 서비스에 테스팅을 적용해보자. 실제 서비스를 개발 완료한 후, 개발자나 QA들은 자신이 만든 서비스가 제대로 동작하는지 테스트해본다. 이때 기능이 많다면 일일이 수작업으로 테스트하기에는 작업량이 너무 많다. 이런 경우 테스트를 자동화하여 프로그램이 프로그램을 테스트하도록 만들기도 한다. 하지만 아무리 테스트를 철저하게 해도 에러를 완전히 막는 것은 불가능하다. NodeBird 프로젝트에 jest 패키지를 설치하자. npm i -D jest package.json을 다음과 같이 수정하자. "scripts": { "start": "nodemon app", "test": "jest" }, routes 폴더 안에 middlewares.test.js를 만들자. 테스트용 파일은 파일명과..

CORS API를 사용하는 서버에서의 호출만 다뤘었다. 만약 프런트에서 호출한다면 어떻게 해야 할까?? CORS를 이용하여 처리하자. router.get('/', (req, res) => { res.render('main', {key: process.env.CLIENT_SECRET}); }); nodecat/routes/index.js 프런트 화면을 렌더링하는 라우터를 추가했다. 프런트 화면도 추가하자. nodecat/views/main.html clientSecret의 {{key}} 부분이 넌적스에 의해 실제 키로 치환돼서 렌더링된다. Access-Control-Allow-Origin이라는 헤더가 없다는 내용의 에러이다. 브라우터와 서버의 도메인이 일치하지 않으면, 기본적으로 요청이 차단된다. 이러한 ..

사용량 제한 일차적으로 인증된 사용자만 API를 사용할 수 있게 필터를 두긴 했지만, 아직 완성은 아니다. 인증된 사용자라고 해도 과도하게 API를 사용하면 API 서버에 무리가 간다. 따라서 일정 기간 내에 API를 사용할 수 있는 횟수를 제한하여 서버의 트래픽을 줄이는 것이 좋다. 이러한 기능은 express-rate-limit패키지에서 제공한다. npm i express-rate-limit verifyToken 미들웨어 아래에 apiLimiter 미들웨어와 deprecated 미들웨어를 추가하자. const jwt = require('jsonwebtoken') const RateLimiter = require('express-rate-limit'); exports.isLoggedIn = (req, ..

SNS API 서버 nodebird-api로 돌아와 API 라우터를 완성해보자. const express = require('express'); const jwt = require('jsonwebtoken'); const { verifyToken } = require('./middlewares'); const { Domain, User, Post, Hashtag } = require('../models'); const router = express.Router(); router.post('/token', async (req, res) => { const { clientSecret } = req.body; try { const domain = await Domain.findOne({ where: { cli..

다른 서비스 호출 API 제공 서버를 만들었으니 API를 사용하는 서비스도 만들어 보자. 이 서비스는 다른 서버에게 요청을 보내므로 클라이언트 역할을 한다. API 제공자가 아닌 API 사용자의 입장에서 진행하는 것이며, NodeBird 앱의 데이터를 가져오고 싶어 하는 사용자인 것이다. { "name": "nodecat", "version": "1.0.0", "description": "노드버드 2차 서비스", "main": "app.js", "scripts": { "start": "nodemon app", "test": "echo \"Error: no test specified\" && exit 1" }, "author": "hvvan", "license": "ISC", "dependencies": ..

JWT 토큰 인증 API 서비스를 제공하는 입장에서 다른 클라이언트가 NodeBird의 데이터를 가져갈 수 있게 해야 하는 만큼 별도의 인증과정이 필요하다. JWT는 JSON Web Token의 약어로, JSON 형식의 데이터를 저장하는 토큰이다. 구성요소는 다음과 같다. 헤더(HEADER): 토큰 종류와 해시 알고리즘 정보가 들어 있다. 페이로드(PAYLOAD): 토큰의 내용물이 인코딩 된 부분이다. 시그니처(SIGNATURE): 일련의 문자열이며, 시그니처를 통해 토큰 변조 여부를 확인한다. 페이로드 부분은 노출된다. 이는 토큰의 내용을 모두 감춘다면 매 요청마다 권한을 체크해야 한다. 따라서 비밀키를 숨긴다. 비밀키는 시그니처와 다른 의미이다. JWT 토큰의 단점은 용량이 크다는 것이다. 내용물이 ..

API 서버 API는 Application Programming Interface의 두문자어로, 다른 애플리케이션에서 현재 프로그램의 기능을 사용할 수 있게 허용하는 접점을 의미한다. 서버에 API를 올려서 URL을 통해 접근할 수 있게 만든 것을 웹 API 서버라고 한다. 프로젝트 생성 이전에 만든 NodeBird와 데이터베이스를 공유하는 서버를 만들자. { "name": "nodebird-api", "version": "1.0.0", "description": "NodeBird API 서버", "main": "app.js", "scripts": { "start": "nodemon app", "test": "echo \"Error: no test specified\" && exit 1" }, "auth..