Nestjs 공식문서 정리

Nestjs

https://docs.nestjs.com/

 

확장 가능하며, 효율적으로 아키텍처를 제공하기 위한 프레임워크, 앵귤러에서 많은 영감을 받음.

 

controller: 어플리케이션 처리를 위한 요청을 받는 것

컨트롤러를 사용하기 위해 데코레이터와 클래스를 사용한다. 

 

컨트롤러의 클래스 위에 @Controller('cats')를 지정하여 prefix처리할 수 있다. @Get, @Post, @Delete 같은 데코레이터를 지원한다. nest g resource [name] 명령어를 통해 한번에 모듈을 생성할 수 있다. 

 

import { Controller, Get, Req } from '@nestjs/common';

import { Request } from 'express';

 

@Controller('cats')

export class CatsController {

  @Get()

  findAll(@Req() request: Request): string {

    return 'This action returns all cats';

  }

}

 

Decorators

@Request(), @Req() req

@Response(), @Res()* res

@Next() next

@Session() req.session

@Param(key?: string) req.params / req.params[key]

@Body(key?: string) req.body / req.body[key]

@Query(key?: string) req.query / req.query[key]

@Headers(name?: string) req.headers / req.headers[name]

@Ip() req.ip

@HostParam() req.hosts

 

@Redirect('https://nestjs.com', 301)

Redirect 데코레이터

 

@Param('id') id: string

Router Parameter 데코레이터

 

body로 들어오는 정보를 받을 때 DTO를 생성하여 처리한다. 

export class CreateCatDto {

  name: string;

  age: number;

  breed: string;

}

 

@Post()

async create(@Body() createCatDto: CreateCatDto) {

  return 'This action adds a new cat';

}

 

컨트롤러는 항상 모듈에 속한다. 모듈 데코레이터 내부에 배열로 Controller를 선언하는 이유다.

 

Providers

service, repository, factory, helper는 provider로 여겨진다. 의존성으로 추가될 수 있다.

 

Service

Controller에서 서비스를 생성자에서 주입하여 사용한다. 모듈의 providers에 서비스를 등록한다. 

 

Module

모듈은 @Module() 데코레이터를 통해 어플리케이션의 구조를 잡는다. 각 어플리케이션은 적어도 1개의 root module을 갖는다. 의존성을 제공하고 모듈과 프로바이더간의 관계를 해결한다. 컴포넌트에 맞게 모듈을 사용하는 것을 권장하므로 대부분의 프로젝트는 다수의 모듈을 가지게 된다. 

 

providers

Nest 인젝터에 의해 처리되며 적어도 이 모듈에서 공유된다.

 

controllers

이 모듈에서 정의되고 초기화되어야 하는 컨트롤러들

 

imports

임포트한 모듈의 리스트

 

exports

다른 모듈에서 사용하는 경우에 처리

 

각 도메인 별로 providers, controllers를 따로 Module로 묶고 이를 App Module에 추가하는 식으로 추상화된다. 다른 모듈에서 사용한 provider가 있는 경우 exports를 선언하여 내보낸다. Nest는 모듈 내에서 providers를 캡슐화한다. (기본적으로 Global scope으로 처리되지 않음)

 

Middleware

route handler 이전에 호출되는 함수이다. request, response 오브젝트를 가지고 있으며 next() 함수를 통해 다음 미들웨어로 처리로 넘어갈 수 있다. 기본적으로 express의 미들웨어와 동일하다. NestMiddleware 인터페이스를 상속 받는 방식과 함수로 정의하는 방식이 존재한다.

 

Exception filters

어플리케이션 전체에서 처리되지 않은 예외에 대한 처리를 하기위한 exceptions layer가 존재한다

 

Pipes

데이터의 형태를 변환하기 위한 용도나 입력 데이터의 검증에서 사용된다. controller의 처리 이전에 호출되며 인자를 받아서 처리한다. 그 이후에 다음 처리가 진행된다. class-validator를 통해 클래스의 멤버에 대한 validator를 설정할 수 있다.

 

Guards 

canActive 인터페이스를 구현한다. 라우터 핸들러에 의해 처리가 되어야 하는지 여부를 검증한다. 권한, 역할 등에 따라 현재 처리할 수 있는지 처리한다. express에서는 미들웨어에서 처리하는 부분으로 각 작업이 강력하게 연결되지 않을 때 선택할 수 있다. 그러나 미들웨어는 다음에 실행해야 할 핸들러를 알지 못한다. 반면 가드는 ExcecutionContext 인스턴스에 접근하므로 어떤 처리를 해야 하는지 명확히 인지하고 있다. req/res 사이클의 정확한 시점에 처리하도록 설계되어 있다.

 

모든 가드는 canActivate 함수를 구현해야 한다. 비동기/동기적으로 처리될 수 있으며 bool값을 반환한다. 가드는 컨트롤러, 메소드 혹은 글로벌하게 적용할 수 있다. 

 

Interceptors

NestInterceptor 인터페이스를 구현하는 데코레이터이다. 

https://docs.nestjs.com/interceptors

 

AOP 프로그래밍의 철학을 따른다.

- 특정 로직을 메소드의 실행 이전/이후에 처리한다.

- 함수에서 반환된 결과를 변형한다.

- 함수에서 처리된 exception을 변형한다.

- 기본 함수의 동작을 확장한다.

- 상태 조건에 따라 함수를 완전히 오버라이딩 한다. (예를 들어 캐싱을 이유로)

 

각 인터셉터는 intercept() 메소드를 구현한다. 첫 인자로 ExcecutionContext 인스턴스를 받으며 두 번쨰 인자로 CallHandler를 받는다. CallHandler는 handle메소드를 구현하는데 인터셉터의 특정 부분에서 route handler 메소드를 호출하는데 사용할 수 있다. (호출하지 않으면 route handler 메소드를 전체적으로 실행되지 않음)

 

이러한 접근은 intercept() 메소드가 req/res 스트림을 효율적으로 감싸는 것을 의미한다. 마지막 라우터 핸들러의 실행 이전과 이후에 커스텀 로직을 구현할 수 있다. handle() 이전에 구현하면 되고, rxjs operator를 통해 handle() 메서드에서 반환되는 Observable 객체를 조작할 수 있다.