왜 Nest.js일까?

보통 Node.js 런타임 위에서 동작하는 백엔드 프레임워크라 하면 2개가 생각날 것입니다.

Express.js

Nest.js

이렇게 2개일 것입니다.
그런데 본격적인 학습에 앞서, 저는 궁금했습니다.

현업에서는 주로 Express보단 Nest를 많이 사용하는데, 대체 왜 그럴까?

이를 알기 위해서는 Express부터 알아야 합니다.
Express를 간단히 소개하자면 , 미니멀리스트 웹 프레임워크. 즉 최소한의 기능을 제공합니다. 따라서 라우터를 사용할 때도 직접 라우터를 추가해야 하고, 에러 핸들링도 try catch로 진행하는 등 대부분을 사용자가 처리해야 합니다.
이 외에도

• 의존성 주입 x
• JS 기본
• 테스트 모듈 x

와 같은 중요한 기능을 express는 지원하지 않습니다.

이같이 express는 최소한의 기능을 제공하고, 구조 자체도 너무나 자유로웠습니다. 명확한 구조와 코딩 스타일도 없었던 express는 협업과 유지보수가 힘들다는 단점이 있었습니다.

위의 단점과 같은 express의 많은 단점을 보완하기 위해 나온 게 Nest.js입니다.

NestJS는 express 기반으로 만들어진, TypeScript용 백엔드 프레임워크입니다.
Nest의 주요 특징은 다음과 같습니다.

• Provider

  @Injectable()
  export class Service {}

  기본적으로 @Injectable() 데코레이터로 나타내며 이름에서도 알 수 있듯이 프로바이더는 다른 프로바이더나 컨트롤러에 주입(Inject)될 수 있습니다.

• Controller
  provider들이 비즈니스 로직을 추상화한다면, Controller는 실제 외부와의 통신과 라우팅 등을 담당합니다.
  

• Module

  @Module({
      imports: [],
      controllers: [],
      providers: [],
      exports: []
      })
      class Module {}

  수평적으로 흩어진 Provider와 Controller들을 논리적인 기능이나 도메인에 따라 하나로 묶어주는 역할을 하며, 재사용성을 높여줍니다.

• 데코레이터
  NestJS 에서는 데코레이터를 사용하는데, HTTP route를 위한 데코레이터, 요청의 param에 대한 데코레이터 등 미리 만들어둔 데코레이터들이 있습니다. 또한 사용자가 정의해서 추가할 수 있습니다.

• Express와의 차이
  express를 보완하기 위해 나온 것이 Nest이고, express에서 지원하지 않는 기능을 Nest에서는 많이 제공합니다. 그러나 재미있는 점은 Nest는 모든 걸 처음부터 개발하지 않고 axios, cookie-parser, multer와 같은 express에서 사용하던 기술을 Nest에서도 사용하고 있다는 점입니다.
  이러한 express 친화적인 부분들이 기존의 개발자들에겐 다른 프레임워크에 비해 훨씬 커다란 장점으로 다가오고, 기존 프로젝트의 마이그레이션 역시 쉽게 진행될 수 있도록 하는 사실 또한 큰 특징이라 볼 수 있습니다.

• TypeScript를 위한 프레임워크
  Nest는 TypeScript를 지원하는 것이 아닌, TypeScript를 쓸 것을 가정하고 만든 프레임워크입니다. 이는 Angular와도 비슷합니다.

위와 같은 이유로, 현재는 express보다는 Nest가 선호됩니다.