미들웨어
미들웨어는 라우터 핸들러 이전에 호출되는 함수이다. 미들웨어 기능은 요청 및 응답 객체에 액세스 할 수 있으며 애플리케이션의 요청/응답 생명 주기 동안 미들웨어 기능을 사용할 수 있다. Nest 미들웨어는 기본적으로 Express 미들웨어랑 동일하다.
미들웨어 생성
CLI를 사용해서 생성
nest g middleware logger
JavaScript
복사
logger 미들웨어를 만들어보자. 특이한 점은 @Injectable 데코레이터가 붙었다는 것!
또 알고 있어야 되는 것은 NestMiddleware가 사용하는 req, res, nextfunction이 Express에서 사용하는 것과 같다는 것이다.
미들웨어 적용
미들웨어를 모듈에 등록하지 못한다.
미들웨어는 의존성 주입을 해야 사용할 수 있다.
하지만 모듈에는 의존성 주입이 되지 않는다.
공식 문서를 살펴보면 @Module에는 미들웨어를 위한 자리가 없다고 한다.
미들웨어를 위한 의존성 문법
→@Module 데코레이터 내부에는 미들웨어를 위한 장소가 없으므로,
→ 미들웨어를 사용하기 위해서는 AppModule이 NestModule을 구현해야된다.
→ configure메소드는 MiddlewareConsumer를 사용하여 미들웨어를 특정 경로에 적용한다.
→ 특정 경로에 적용할 미들웨어를 LoggerMiddleware로 설정하고, 경로도 지정한다. (’cats') 경로에 와일드카드 * 로 지정하면 모든 요청에 대한 미들웨어가 될 수 있다. 인터셉터 같이
경로에 와일드카드 * 로 지정하면 모든 요청에 대한 미들웨어가 될 수 있다. 인터셉터 같이 미들웨어 테스트
모든 경로 테스트
미들웨어를 모든 경로에 적용해서 한 번 테스트 해보자.
어떤 경로를 요청해도 ‘Hello, World’ 가 찍혀야되고, 미들웨어 로그인 req.ip 도 찍혀야 된다.
postman 확인
return 값은 잘 찍혔다.
console 확인
→ console.log로 요청했던 것은 요청 객체의 ip주소였다.
→ 루트백주소이기 때문에 ::1이 찍힌 것을 확인할 수 있다.
→ ::1 은 IPv6의 루프백 (loopback)주소를 가리킨다. 자기 자신의 주소를 말한다.
Logger
우리는 이제것 console.log로 로그를 확인했지만, Nest에서 사용하는 로깅 라이브러리가 있다. 그게 바로 Logger 이다.
이렇게 LoggerMiddleware 에 new로 Logger를 띄우고 재요청을 해보자.
postman 확인
postman은 기존과 변함없이 반환한다.
console 확인
기존 로그와 같은 형태로 나온다.
아까 Logger를 띄울 때 입력했던 문자열 HTTP는 여기에 구분자로 들어가게 된다.
response에도 미들웨어를 사용할 수 있다.
res.on 메소드로 응답에 미들웨어를 달 수 있다.
위의 코드로
응답의 ip, method, statusCode 와
요청의 originalUrl을 알 수 있다.
확인
요청에 대한 로그와, 응답에 대한 로그가 다 같이 찍혔다.