[NestJS] NestJS 입문 : 구조적 백엔드 개발을 위한 첫걸음🚀

Nest.js 스터디를 시작했다. 책이 왔지만, 이렇게 일찍 올 줄 몰랐어서 이번 주 과제는 인프런 무료 강의를 섹션 3까지 듣고 오는걸로 했다. 막상 듣고보니 너무 초반 부분이긴 했지만, Nest 맛보기에는 충분했음!
 
강의 링크

[지금 무료]따라하며 배우는 NestJS 강의 | John Ahn - 인프런

---

😺Nest.js란?

NestJS는 효율적이고 확장 가능한 Node.js 서버 측 애플리케이션을 구축하기 위한 프레임워크이다. Javascript와 Typescript 사용이 가능하며, 객체지향, 함수형, 함수형 반응형 프로그래밍 요소를 모두 활용할 수 있다.
 
내부적으로는 Express와 같은 HTTP 서버 프레임워크를 사용하지만, 선택적으로 Fastify로 대체할 수도 있다. NestJS의 큰 장점은 기존 프레임워크 위에 추상화 계층을 제공하면서도, 필요할 때는 Express나 Fastify의 API를 직접 사용할 수 있게 해준다는 점이다.

NestJS 철학

Node.js 생태계에는 이미 많은 라이브러리와 도구가 있지만, 아키텍처 측면의 문제를 효과적으로 해결해주는 것은 많지 않았다. NestJS는 Angular에서 영감을 받아, 개발자들이 테스트하기 쉽고 확장 가능하며 유지보수가 용이한 애플리케이션을 만들 수 있도록 구조화된 아키텍처를 제공한다.
Express만 사용할 때는 테스트, 로깅, 유효성 검사 등의 기능을 일일이 설정해야 했지만, NestJS는 이런 기능들을 명령어 하나로 쉽게 추가할 수 있게 해준다.
 

NestJS 시작하기

npm i -g @nestjs/cli
nest new project-name

위 명령어로 NestJS CLI를 설치하고 새 프로젝트를 생성할 수 있다. 새 프로젝트가 생성되면 초기 핵심 파일과 폴더 구조가 자동으로 만들어진다.

설치 콘솔이 귀여워서 좀 반함

CLI를 사용하는 이유

NestJS CLI는 단순히 프로젝트를 생성하는 것 이상의 기능을 제공한다. 모듈, 컨트롤러, 서비스 등의 컴포넌트를 쉽게 생성할 수 있고, 프로젝트 빌드와 실행도 간편하게 할 수 있다. 또한 Hot Reload 지원으로 개발 생산성을 크게 향상시킬 수 있다.
주요 명령어는 다음과 같다:

nest new [프로젝트명]    // 새 프로젝트 생성
nest generate [항목]     // 컴포넌트 생성
nest build              // 프로젝트 빌드
nest start              // 서버 실행

---

😸NestJS 구조

앱 구조

아래 구조는 강의에서 다루는 CRUD 프로젝트에 대한 애플리케이션 구조이다.

NestJS 애플리케이션은 일반적으로 여러 모듈로 구성된다. 예를 들어 게시판 애플리케이션은 다음과 같은 구조를 가질 수 있다:

App module

-   게시글을 만드는 사람에 대한 인증 모듈(AuthModule)
    -   AuthController
    -   UserEntity
    -   AuthService
    -   UserRepository
    -   JWT, PassPort
-   게시글에 대한 모듈(BoardModule)
    -   BoardController
    -   BoardEntity
    -   BoardService
    -   BoardRepository
    -   ValidationPipe

 

프로젝트 기본 생성 파일

NestJS 프로젝트를 생성하면 여러 설정 파일들이 자동으로 만들어진다. 각 파일의 역할은 다음과 같다:

• eslintrc.js: 특정한 규칙을 가지고 코드를 깔끔하게 짤 수 있게 도와주는 라이브러리(문법 오류 체크 등)
• prettierrc: 코드 형식을 맞추는데 사용(에러는 찾지 않고, 코드 포맷터 역할을 함)
• nest-cli.json: nest 프로젝트를 위해 특정한 설정을 할 수 있는 json 파일
• tsconfig.json: 어떻게 타입스크립트를 컴파일할지 설정하는 파일
• tsconfig.build.json: tsconfig.json의 연장선상 파일일, 빌드를 할 때 필요한 설정들을 작성하는 파일

{
  "extends": "./tsconfig.json",
  "exclude": ["node_modules", "test", "dist", "**/*spec.ts"] //빌드할 때 필요없는 파일들 명시
}

• package.json: 명령어, 의존성 등이 작성되어 있는 파일
• src 폴더: main.ts는 앱을 생성하고 실행, app.module.ts는 앱 모듈을 정의

 

NestJS 로직 흐름

NestJS 애플리케이션의 요청 처리 흐름은 다음과 같다:

1. 시작점 (Entry Point) main.ts
   • 애플리케이션의 시작점으로, NestFactory를 사용해 앱 인스턴스를 생성하고 HTTP 서버를 시작한다.
2. 모듈 (Module) app.module.ts
   • 애플리케이션의 루트 모듈로, 컨트롤러와 서비스를 등록하고 관리한다.
   • 의존성 주입의 기반이 된다.
3. 컨트롤러 (Controller) app.controller.ts
   • HTTP 요청을 처리하고 라우팅을 담당한다.
   • 클라이언트의 요청을 받아 서비스로 전달하는 역할을 한다.
4. 서비스 (Service) app.service.ts
   • 실제 비즈니스 로직을 처리하고 데이터를 관리한다.
   • 컨트롤러로부터 받은 요청을 처리하고 결과를 반환한다.
5. 요청-응답 사이클
   • 클라이언트가 요청을 보내면 컨트롤러가 이를 받아 서비스에 전달하고, 서비스가 처리한 결과를 다시 컨트롤러를 통해 클라이언트에게 응답한다.

⭐ 기본적인 요청 흐름은 request -> controller -> service -> controller -> response 구조로 이루어진다.

---

😹NestJS 모듈

모듈은 @Module() 데코레이터로 주석이 달린 클래스이다. NestJS 애플리케이션은 최소한 하나의 루트 모듈이 필요하며, 이 모듈을 시작점으로 애플리케이션이 구성된다.

 
모듈은 관련된 기능을 그룹화하는 효과적인 방법이다. 예를 들어 사용자 관리, 게시판 관리 등의 기능을 각각 별도의 모듈로 분리할 수 있다. 각 모듈은 자신만의 컨트롤러, 서비스, 기타 프로바이더를 가질 수 있다.
 
NestJS의 모듈은 기본적으로 싱글톤으로 관리되기 때문에, 여러 모듈에서 동일한 프로바이더 인스턴스를 공유할 수 있다. 이는 메모리 효율성과 상태 관리 측면에서 큰 장점이다.
 
모듈의 기본 구조는 다음과 같다:

@Module({
  imports: [관련 모듈들],
  controllers: [해당 모듈의 컨트롤러들],
  providers: [해당 모듈의 서비스들],
  exports: [다른 모듈에서 사용할 수 있게 내보낼 서비스들]
})

새 모듈은 CLI를 통해 쉽게 생성할 수 있다:

nest g module boards

위 명령어를 실행하면 boards 폴더가 생성되고 그 안에 모듈 파일이 자동으로 추가된다.
 

NestJS 컨트롤러

컨트롤러는 클라이언트로부터 들어오는 요청을 처리하고 응답을 반환하는 역할을 한다. @Controller 데코레이터를 사용하여 정의하며, 이 데코레이터에는 해당 컨트롤러가 담당할 라우트 경로를 지정할 수 있다.

 

예를 들어 @Controller('boards')로 정의하면 이 컨트롤러는 /boards 경로로 들어오는 모든 요청을 처리하게 된다.

컨트롤러는 CLI를 통해 쉽게 생성할 수 있다:

nest g controller boards --no-spec

여기서 --no-spec 옵션은 테스트 파일을 생성하지 않도록 지정하는 것이다.

 

NestJS 핸들러

핸들러는 컨트롤러 클래스 내부에 정의된 메서드로, HTTP 요청 메서드(@Get, @Post, @Delete 등)에 대응하는 데코레이터로 장식된다. 이 메서드들은 클라이언트의 특정 요청을 처리하는 역할을 한다.

 
예를 들어:

@Get()
getAllBoards() {
  return this.boardsService.getAllBoards();
}

이 메서드는 GET 요청이 컨트롤러의 기본 경로(/boards)로 들어올 때 실행된다.

 

NestJS 프로바이더

프로바이더는 NestJS의 핵심 개념 중 하나로, 다양한 종류의 서비스, 리포지토리, 팩토리, 헬퍼 등이 모두 프로바이더로 취급될 수 있다. 프로바이더의 주요 특징은 의존성 주입(Dependency Injection)을 통해 다른 컴포넌트에서 사용될 수 있다는 점이다.
 

모듈에서 프로바이더를 등록하려면 @Module 데코레이터의 providers 배열에 추가하면 된다:

@Module({
  controllers: [BoardsController],
  providers: [BoardsService]
})

 

NestJS 서비스

서비스는 애플리케이션의 비즈니스 로직을 담당하는 프로바이더이다. @Injectable 데코레이터로 표시되며, 이를 통해 NestJS의 의존성 주입 시스템에 등록된다.

 
컨트롤러는 HTTP 요청과 응답을 처리하는 역할에 집중하고, 복잡한 작업은 서비스로 위임하는 것이 일반적이다. 예를 들어 데이터베이스 조회, 유효성 검사, 비즈니스 로직 등의 작업은 서비스에서 처리한다.
 
서비스는 CLI를 통해 쉽게 생성할 수 있다:

nest g service boards --no-spec

---

💉의존성 주입(Dependency Injection)

의존성 주입은 NestJS의 핵심 기능 중 하나로, 컴포넌트 간의 결합도를 낮추고 코드의 재사용성과 테스트 용이성을 높이는 방법이다. NestJS에서는 클래스의 생성자를 통해 의존성을 주입한다.
 
예를 들어, BoardsController에서 BoardsService를 사용하려면 다음과 같이 작성한다:

@Controller('boards')
export class BoardsController {
  constructor(private boardsService: BoardsService) {}

  @Get()
  getAllBoards() {
    return this.boardsService.getAllBoards();
  }
}

여기서 private boardsService: BoardsService는 TypeScript의 단축 구문으로, 다음과 같은 의미를 갖는다:

1. BoardsService 타입의 파라미터를 생성자에서 받는다.
2. 이 파라미터를 클래스의 private 속성으로 자동 저장한다.

이는 다음 코드와 동일하다:

@Controller('boards')
export class BoardsController {
  private boardsService: BoardsService;

  constructor(boardsService: BoardsService) {
    this.boardsService = boardsService;
  }
}

이렇게 의존성을 주입받으면 컨트롤러 내의 모든 메서드에서 this.boardsService를 통해 서비스의 기능을 사용할 수 있다. NestJS는 자동으로 BoardsService의 인스턴스를 생성하고 BoardsController의 생성자에 전달해준다.

 
위 코드는 다음과 같은 동작 과정을 가진다:

1. NestJS가 BoardsController를 초기화할 때, BoardsService의 인스턴스가 필요하다는 것을 인식한다.
2. NestJS는 BoardsService의 인스턴스를 생성한다 (또는 이미 존재하는 인스턴스를 재사용한다).
3. 이 인스턴스를 BoardsController의 생성자에 파라미터로 전달한다.
4. TypeScript의 단축 구문 덕분에, 이 인스턴스는 자동으로 컨트롤러의 boardsService 프로퍼티에 할당된다.
5. 이제 컨트롤러의 모든 메서드에서 this.boardsService를 통해 서비스의 메서드를 호출할 수 있다.

---

💔NestJS의 싱글톤 모듈 시스템

NestJS에서 모듈과 프로바이더는 기본적으로 싱글톤 패턴으로 관리된다. 이는 애플리케이션 전체에서 해당 클래스의 인스턴스가 단 하나만 생성되고 공유된다는 의미이다.
 
이러한 싱글톤 특성은 다음과 같은 장점을 제공한다:

1. 메모리 효율성: 동일한 서비스나 컴포넌트를 여러 번 생성하지 않아 메모리 사용량이 감소한다.
2. 상태 공유: 여러 모듈에서 동일한 서비스 인스턴스를 사용하므로 상태 관리가 일관되게 이루어진다.
3. 성능 향상: 데이터베이스 연결이나 외부 API 클라이언트와 같은 리소스를 한 번만 생성하여 사용할 수 있다.

모듈 간에 프로바이더를 공유하기 위해서는 다음과 같이 설정한다:

// 모듈 A에서 서비스 정의 및 내보내기
@Module({
  providers: [SharedService],
  exports: [SharedService]
})
export class ModuleA {}

// 모듈 B에서 모듈 A 가져오기
@Module({
  imports: [ModuleA],
  controllers: [SomeController]
})
export class ModuleB {}

이렇게 하면 ModuleB의 컨트롤러나 서비스에서 ModuleA의 SharedService를 의존성 주입을 통해 사용할 수 있다.
 
예를 들어, 카운터 서비스를 여러 모듈에서 공유하는 경우:

// 모듈 A에서 정의한 서비스
@Injectable()
export class SharedService {
  private count = 0;

  incrementCount() {
    this.count++;
    return this.count;
  }
}

// 모듈 A
@Module({
  providers: [SharedService],
  exports: [SharedService], // 다른 모듈에서 사용할 수 있도록 내보내기
})
export class ModuleA {}

// 모듈 B
@Module({
  imports: [ModuleA], // ModuleA의 서비스를 가져와 사용
  controllers: [SomeController],
})
export class ModuleB {}

이제 ModuleB의 컨트롤러에서 SharedService를 주입받아 사용할 수 있다:

@Controller('some')
export class SomeController {
  constructor(private sharedService: SharedService) {}

  @Get('increment')
  increment() {
    return this.sharedService.incrementCount();
  }
}

이 컨트롤러에서 /some/increment 엔드포인트에 접근할 때마다 카운터가 증가하고, 이 카운터 값은 애플리케이션 전체에서 공유된다. 다른 모듈에서 같은 SharedService를 사용하면 동일한 카운터 값을 볼 수 있다.

 
싱글톤 패턴은 NestJS의 핵심 설계 원칙 중 하나로, 모듈과 서비스의 효율적인 재사용과 의존성 관리를 가능하게 하는 중요한 개념이다. 데이터베이스 연결, 캐시 서비스, 설정 관리 등 애플리케이션 전체에서 일관된 상태가 필요한 경우에 특히 유용하다.

---

코드를 이해하는게 조금 어렵긴 했다. 의존성 주입이며 싱글톤 패턴이며 제대로 공부해본 적 없는 내용들이 휘몰아쳐서 잠깐 고비가 있었지만, 강의 분량도 짧고 설명도 쉬워서 무사히 첫 주 미션을 완수할 수 있었다. CLI를 통해 모듈, 컨트롤러, 서비스를 만드는데 너무 편리해서 NestJS 첫인상은 진짜 최고.