NestJS를 사용해야 할 이유
Express를 사용해야 할 이유 (1)을 쓰면서 NestJS는 굉장히 매력적인 대상으로 다가왔다. 이번 글에서는 NestJS를 사용해야 할 이유를 조금 더 자세히 정리하고, NestJS를 간략히 알아본다.
NestJS를 사용해야 할 이유
NestJs만의 장점이 뭐가 있을까? 생각보다 좀 있었는데, 아무래도 Rich Framework의 특징을 많이 갖고 있다.
| 장점 | 설명 |
|---|---|
| CLI | 생산성에 도움이 되는 유틸을 제공한다고 한다. |
| 문서화 | 자세하고 유지보수가 잘 되는 문서를 갖고 있다고 한다. (타 프레임워크에 비해 기능이 훨씬 많은데도) |
| 활성화된 개발 팀 | 이전 글에서 알아본 바로 이는 굉장히 특장점이다. (다른 언어에 비해 백엔드가 많이 약하다고 생각함) |
| Nest 전용 모듈 | Spring처럼 타 라이브러리를 쉽게 사용할 수 있게 전용 모듈을 개발했다. TypeORM, Mongoose, GraphQL, Logging, Validation, Caching, WebSockets 등의 모듈이 있다고 한다. |
| MSA를 염두에 둔 설계 | (이건 내가 MSA에 대한 이해가 적어서 얼마나 효과적일지 모르겠음.) |
| Typescript 채택 | (Typescript 경험이 일천해 얼마나 효과적일지 모르겠음.) |
| 테스트 용이성 | 프레임워크 핵심 가치에 테스트 용이성이 있고 프레임워크에서 설계를 제공하므로, 다른 프레임워크에 독자적인 설계를 했을 때보다 테스트가 용이할 것으로 기대됨. |
NestJS를 사용하는 기업
사용하는 기업 목록 중 SW적으로 큰 기업이 없는데 무슨 이유일지 모르겠다. 분명 시장의 선택은 합리적일텐데 정말 선택받지 못한거라면 중요한 문제가 있을 거라는 합리적인 의심을 해볼 만하다.
NestJS의 핵심
패러다임
Typescript를 지원하면서 OOP, FP, FRP(Functional Reactive) 요소를 조합한 백엔드 프레임워크이다.
Typescript 사용은 강제가 아니다.
Express, Fastify 를 기반해 개발됐고, NestJs가 윗단으로 추상화 계층을 제공하지만 바로 접근할 수도 있다.
NestJs는 Node.js HTTP 프레임워크 추상화 계층을 구현해놓았기 때문에, Express, Fastify 이외에도 Adapter 패턴을 통해 인터페이스 구현체만 제공한다면 어떤 기술 위에서도 작동할 수 있다고 한다. 아마 Fastify로 이주할 때 개발해 놓은듯하다.
@nestjs/platform-expres,@nestjs/platform-fastify로 패키지가 분리돼있으니 참고해보면 재밌을 것 같다.
다만 NestJs에서 Express 생태계가 필요할 것 같지도 않고 Fastify가 훨씬 빠른데 굳이 Express를 기본값으로 해놓은 이유는 모르겠다.
NestJs는 Typescript를 사용하지 않는다면 Babel이 필요하다고 하며 Node.js 10.13버전 미만으로는 지원하지 않는다.
Typescript가 정확히 어떤 Javascript 버전까지 지원하는지 확인할 수 없었는데 조만간 Typescript를 학습하면서 정리해야겠다.
목표
프론트 3대 프레임워크 덕분에 개발자 생산성이 향상됐고 빠르고 테스트 가능하고 확장성있는 프론트엔드 개발이 가능해졌는데, 그 외 좋은 라이브러리들이 많지만 애플리케이션 구조, 설계 측면의 문제를 해결하는 프로젝트는 없었다. (이건 Javascript 계열의 특징이라고 생각한다. 아마도 대규모로 개발하는 제품에 Javascript를 쓰지 않기 때문인 것으로 보인다. 요즘은 언어가 많이 좋아졌는데도 말이다.)
NestJs는 애플리케이션 아키텍처를 제공한다(즉 개발자가 결정하는 게 아님). 테스트 가능하고, 확장성 있고, 느슨히 결합되고, 쉽게 유지보수 가능한 설계이다. Angular에서 영감을 받았다. (Angular는 강제성 있는 구조를 제공한다. React는 그 반대이고.)
NestJS Docs Intro 요약
문서의 내용을 요약했다.
프로젝트 제너레이터
nest new {project_name} 을 입력하면 프로젝트 폴더가 생성된다. (npm i -g @nestjs/cli로 설치되는 CLI 유틸인듯)
기본으로 생성되는 프로젝트 구조는 아래와 같다. 도메인이나 레이어 별로 폴더가 나뉘진 않는 듯하다.
src
- app.controller.ts
- app.controller.spec.ts
- app.module.ts
- app.service.ts
- main.ts
아래는 Express에서의 파일 역할 비교이다.
| file | NestJS | Express |
|---|---|---|
| Controller | app.controller.ts | (사용자 나름) |
| Service | app.service.ts | (사용자 나름) |
| App | app.module.ts | App.js |
| Index (진입점) | main.ts | index.js |
재밌는 문서 구성
아래는 몇 개의 하위 문서에 들어갔을 때 맨 위에 보이는 모식도 몇 개를 가져온 것이다.
Spring에서도 제공하지 않는 모식도를 Nest에서 제공하는 게 재밌었는데,
- 개발진들이 정말 OOP를 좋아하는 것 같다고 느껴졌고
- 그래서 오브젝트 책을 보면서 같이 배우면 재밌을 것 같았고
- Spring에 비해 Nest는 확실히 설계를 결정해주는 느낌이 들어서 자신감이 느껴졌고
그동안 설계를 정해준 프레임워크는 사용해 본적이 없었는데 받아들이기만 한다면 생산성도 꽤 좋아질 것 같다. 설계 수준 또한 오픈 소스로 개발되니 어느 정도 검증됐을 거라고 생각한다. 따라서 꽤 좋은 학습 경험을 주지 않을까 생각이 든다.
출처: