Nest를 사용해야 하는 이유

물론 부캠에서 Nest를 사용하라는 반강제적인(?) 멘트가 있었지만, 왜 사용하는지는 알고 써야하지 않을까? 싶어서 한번 정리해본다.

일단 한마디로 말하자면, NestJS는 서버 측 어플리케이션 개발에서 아키텍처 문제를 해결하기 위해 등장하였다.

** 서버 개발에서 아키텍처는 쉬운 테스트, 쉬운 확장, 각 모듈 간의 낮은 의존성(⇒ 유지보수 Good)을 가질 수 있게끔 만들어주기 때문에 필요하다.

🤔 Express와 비교해 생각해보자

우리는 부스트캠프 미션을 진행하며 Express를 사용해보았다. 모두가 좋은 아키텍처 설계를 위해 고민했고 대체로 비슷하게 설계했지만 (controller, service, router, model, repository …) 구조에 관한 정의가 없어 각자의 입맛에 구현된 부분들도 많다.

만약 Express로 협업이 진행된다면, 서로의 코드를 이해하고 맞추기 위한 커뮤니케이션 비용(잘은 모르겠지만 시간?효율성?이 많이 떨어지겠지)이 많이 증가할 것이다. 그러나 NestJS는 아키텍처에 대한 정의를 제공하기 때문에 정해진 틀 내에서 간편하게 코드를 작성할 수 있다. (아마도 각자의 코드 스타일만 좀 맞추면 되지 않을까…?)

그냥 한마디로 말하면 완전관리형 프레임워크라서 협업에 좋은 것 같음.

(스프링과 비슷한 추상화 계층을 갖는)

이외에도 업데이트가 적극적으로 이뤄지고 있다.

(물론 아직 성장 중인 프레임워크라 그럴 순 있는데, 계속 향상되면 안 쓸 이유가 없지 않을까)

** [Express]는 Micro Framework (최소한의 것만 지원)라 불린다.

정해져있는 추상화 계층이 존재하지 않는다.

라우터 관리가 깔끔하다.

프레임워크가 IoC, DI를 지원하지 않아 라이브러리를 설치해야 한다.

but 업데이트가 멈춤 ㅠㅠ (2022년 기준 이전 2년간 없었다고 함)

🐯 NestJS

= 서버 프레임워크

• Express or Fastify 프레임워크를 wrapping하여 동작한다.

• 대부분 클래스로 설계됨

• 싱글톤 패턴을 지향 (인스턴스 생성 X, 모듈 통해 inject)

• TypeScript가 기본 언어

• 구성 (다른 글에서 소개해서 간단히 정리해봄)

  • 모듈식 아키텍처

  

  (모듈: 밀접하게 관련된 기능들의 집합)

  → 하나의 비즈니스 로직을 가지며, 싱글톤 ⇒ 동일한 인스턴스 공유 O

  • Controller (like express의 router)

    요청을 처리하고 응답을 반환 (req, res 객체는 데코레이터를 통해 손쉽게)

  • Provider

    종속성 주입 (컨트롤러에 필요한 서비스를 넣어줌)

    → 데이터 유효성 체크, DB에 아이템 생성

    → (종류) 서비스, 리포지토리, 팩토리, 헬퍼

  • Export

    providers에서 제공하는 모듈이 포함되어 있음

** 프레임워크(→ 설계도/어떤 구조가 이미 형성된)

→ 폴더명, 파일명 등에 대한 규칙 존재

→ 자동화가 되어있어 이를 자유롭게 활용하기만 하면 되는?

vs 라이브러리(→ 공구)

** Fastify (사용률이 낮아 제공되는 정보 자체도 적다고 함)

• 성능이 세 개의 프레임워크 중 가장 좋다

  (플러그인에 대한 전체 캡슐화 / 초당 최대 3만 개의 요청 처리 가능)

• 데코레이터, 플러그인 등을 지원해 확장성이 좋다

• JSON 스키마를 사용해 데이터의 유효성 검증 가능