이것 또한 100%에 가까울 정도로 면접 질문을 받게 될 것이라 생각한다.
NodeJS의 프레임워크 생태계에서 사실상 1등을 차지하고 있는 것이 express이다.
하지만 왜 NestJS로 프로젝트를 만드셨습니까?
라는 질문에 대하여 완성도 있는 대답을 하고 싶기에 작성하는 포스트다.
사실 원래는 공식문서나 그런것들을 뒤져가면서 적다가 뭔가 아쉽다는 생각이 들었다.
어? 이렇게는 너무 겉핥기같은데?
그래서 커뮤니티에 한번 물어봤더니 선배 개발자분들께서 이런 이야기를 해주셨다.
nestjs의 특징을 설명할 주제들
- 익스프레스의 문제를 서술해보시는 것은 어떤가요?
- 장고나 스프링과 익스프레스의 차이점을 적어보시는 것은 어떤가요?
- 장고나 스프링이 그런 아키텍처를 가지게된 이유를 적어보시는 것은 어떤가요?
- nestjs 개발자들이 지향하는 추상화 계층이 express와 fastify에는 어떻게 구현이 되어있는지
- request/response pipeline 상의 middleware, guard, interceptor 같은 역할을 express를 직접 쓰는 것과 비교해서 장점을 이야기해보시면 좋을 것 같아요.
내가 생각하는 것과 결은 비슷하지만, 더욱 더 심도있는 차이를 알 수 있도록 조언을 해주셨다.
왜냐하면 내가 알고있는 NestJS의 장점은 아래와 같다.
- 익스프레스의 프레임워크는 아키텍처의 제약이 없다.
1-1. 자유도가 너무 높기 때문에 장점도 있지만, 초기 아키텍쳐를 구성하는 것에서 큰 에로사항이 발생했다. - 이러한 문제를 해결하기 위하여 스프링과 파이썬에서는 아키텍처의 구성 방법에 제약을 뒀다.
- NestJS의 기존 NodeJS 백엔드 진영의 프레임워크의 문제를 개선하기 위하여 아키텍처의 제약을 둠으로써 이러한 문제를 해결했다.
이렇게 간단하게만 알고 있어서 서술하고 있다가 위와 같은 꿀과 같은 이야기를 듣고 찾던 와중 한가지를 더 알려주셨다.
시간이 좀 걸리더라도 NestFactory, INestApplication, NestExpressApplication
순으로 인터페이스 파일들을 읽어보세요. 큰 구조 뿐만 아니라 각각의 express method들이
어떻게 wrapper function으로 제공되는 지 알 수 있습니다.
지금까지 나에게 Node_modules은 문법에러가 발생하였을 경우 참고하는 정도로 그치고 있었는데
Nest를 사용하면서도 Nest의 구성에 대해서는 생각을 한번도 해보지 않았던 것이였다(....)
그래서 이러한 내용을 적어나가는 포스팅이 될 것 같다!
물류 서비스 Backend Software Developer