기본적으로 스프링에서는 다음과 같은 요청의 흐름이 있습니다. (스프링 시큐리티 필터의 경우 DelegatingFilterProxy 라는 필터를 만들어 메인 Filter Chain에 추가하여 동작하는데 DelegatingFilterProxy는 서블릿 컨테이너 영역의 필터와 ApplicationContext에 Bean으로 등록된 필터를 연결시켜주는 역할을 합니다.)
이 요청 흐름은 스프링을 공부하고 사용하고 계신 분들이라면 모두 알고 있을겁니다.
그리고 저희 테크팀에서도 처음 NestJS를 사용하면서 가장 먼저 관심을 가지게 된것은 이러한 요청 생명 주기 였습니다.
기본적으로 NestJS의 요청 흐름은 다음과 같이 이루어 집니다.
- Middleware : 가장 먼저 전역으로 설정된 미들웨어 부터 실행되며, 이후 각 모듈에 설정된 미들웨어가 추가된 순서대로 작동.
- Guards : 전역 가드, 컨트롤러 가드, 라우터 가드 순서대로 작동.
- Pre Interceptors : 컨트롤러(요청에 대한 라우터 핸들러) 전에 실행되는 인터셉터.
- Pipes : 컨트롤러 요청 전에 작동되며, 요청 데이터를 변경하거나 유효한지 체크하는등으로 사용합니다. (ex. ValidationPipe)
- Controller : HTTP 요청을 처리하고 클라이언트 응답에 반환
- Service : 요청에 대한 비즈니스 로직 처리 및 결과값 반환
- Post Interceptor : 컨트롤러 후에 실행되는 인터셉터.
- Exception filters : Response 직전의 예외 레이어로 모든 예외를 처리.
NestJS 요청 흐름은 스프링의 요청 흐름과 매우 유사하다는 것을 알수 있습니다. 그러나 자세히 보면 서비스 레이어등에서 자주 사용하는 AOP 모듈은 없는 것을 알 수 있습니다.
이 부분의 경우 NestJS 측에서는 아직 생각이 없는 것으로 보여서 테크팀에서는 데코레이터를 활용하여 AOP를 개발하려고 하였으나, 이미 토스팀에서 멋진 소스를 개발하여서 공개 하여주셨고, 해당 모듈을 사용하기로 결정 하였습니다.
https://github.com/toss/nestjs-aop
소스코드를 확인하니 사용법은 매우 간단하였고, 우리 테크팀에서는 약간의 커스텀을 가하여 우리 프로젝트 맞게 수정을 하였고, 서비스 레이어에서 매우 유용하게 사용하고 있습니다.
해당 기술을 소개하는 유투브 영상도 개인적으로 매우 추천하는데 코어 모듈까지 분석하여서 작동원리를 파악하여 해당 라이브러리를 개발한것을 보고 감탄을 금치 못하였습니다.
마지막 AOP까지 더해지자 정말 스프링 프레임워크 비교하여도 부족함이 없을 정도로 훌륭한 서버 프레임워크라는 생각이 들었습니다.
이상 요청 생명 주기에 대한 글을 마치며, 다음글에서는 로깅(logging) 방법에 대해 간단하게 설명하도록 하겠습니다.
'Backend(Framework) > NestJS' 카테고리의 다른 글
NestJS Cors와 Cookie설정 (0) | 2023.12.02 |
---|---|
NestJS Yaml 파일 설정 관리 (1) | 2023.12.02 |
NestJS 스웨거(Swagger) 설정 (1) | 2023.12.02 |
NestJS 로깅(logging) 처리 (0) | 2023.12.02 |
NestJS를 사용하게 된 이유 (2) | 2023.11.30 |