Filter도 결국 middleware에서 처리할 수 있을거 같은데 나누는 이유가 있을까요?

안녕하세요 규섭님 :)

우선, 사용자의 요청이 들어올 때 네스트에서는 아래 단계를 거쳐 로직이 수행됩니다.

0. 요청

1. middleware (미들웨어) 

2. guards (가드)

    - 주로 permission (인증) 처리를 할 때 사용합니다.

3. pre-interceptors (인터셉터) 

    - 주로 post-interceptor를 위한 변수 선언, 함수 실행을 합니다. (선택)

4. Pipes (파이프)

    - 변환(요청 바디를 원하는 형식으로 변환), 유효성 검사를 합니다.

5. Controller (컨트롤러)

    - 라우터 역할을 수행합니다. (서비스 로직의 결과를 응답합니다.)

6. Service (서비스 ; 컨트롤러 안에 정의되어 있다면)

    - 해당 요청에 대한 핵심 로직이 수행됩니다.

7. post-interceptor (인터셉터) 

    - 주로 pre-interceptor 로직을 가지고 응답한 데이터를 가공하거나 전체 로직의 속도를 측정합니다. 최종적으로 성공적인 응답 데이터를 보냅니다.

8. exception filters (필터)

    - 예외 처리를 담당합니다. 에러 메세지를 원하는 형태로 가공해서 응답합니다.

9. 응답

이렇게 공통된 역할이 있는 레이어를 나눔으로써 로직을 레고처럼 맞춰서 사용할 수 있습니다. (AOP)

물론 미들웨어에서 res.on("finish", ... )처럼 post-interceptor의 역할을 대신하거나 특정 로직으로 exception filter 대신에 사용할 수 있지만 네스트가 제공해준 역할에 맞게 각 레이어를 사용하면 책임을 분리하고 가독성 높고 확장성 있게 개발할 수 있습니다. 따라서 각각의 목적에 맞게 레이어를 사용하는 것을 추천드립니다.

https://docs.nestjs.com/faq/request-lifecycle

감사합니다.