일반적인 Node.js 데이터베이스 통합 라이브러리 또는 ORM을 직접 사용

NestJS 에서는 TypeormModule 을 예로 드나, 실 사용 환경과는 맞지 않아 정리하지 않음

테스트는 모의 레포지토리를 만들어서 해결할 수 있음

forRootAsync() 메서드로 비동기 호출 가능

• 팩토리 함수
• useClass 를 통해 DB Module Factory 인터페이스를 구현해 적용 가능
• useExisting 구문을 통해 기생성된 provider 참조 가능

일반적으로는 각 환경에 맞는 .env 파일에 따라 정의

• .env 파일을 로드하는 ConfigService를 노출하는 ConfigModule을 만드는 것

기본적으로는 forRoot() 메서드 활용

• .env 파일에 대한 경로는 envFilePath 속성 적용

전역으로 사용하려면 import 하거나 isGlobal 속성 사용

커스텀 구성 파일을 활용해 복잡한 config 환경 조성 가능

export default () => ({
  port: parseInt(process.env.PORT, 10) || 3000,
  database: {
    host: process.env.DATABASE_HOST,
    port: parseInt(process.env.DATABASE_PORT, 10) || 5432
  }
});

• 해당 내용을 load 속성을 사용해서 적용

차후에, 환경 번수에 접근하려면 configService를 활용하는데,

• configService.get() 메서드를 사용
• typescript 의 인터페이스를 활용해 type 도움을 사용 가능

registreAs를 통해 그룹화된 config 환경을 제공할 수도 있음 cache 속성을 통해 환경 변수 caching 가능

기능 모듈 내에서 forFeature 메서드를 통해 부분 등록이 가능함

Joi 패키지, custom validate() 를 통해 환경 변수에 대한 검증도 가능

• validationSchema 속성

custom getter 함수를 만들어 더 효율적인 방식 동작 가능

.env 파일이 로드되기 전에 process.env에 접근되는 것을 방지하기 위해 ConfigModule.envVariablesLoaded 속성에 사용이 가능하다.

ConditionalModule 을 통해 조건부 환경 구성이 가능

• ConfigModule이 애플리케이션에 우선 로드
• ConfigModule.envVariablesLoaded 사용

${} 문법을 통해 config 에 변수 적용 가능 또, expandVariables 옵션을 통해 환경 변수 확장 가능

Jest 가 기본 테스트 프레임워크로 제공됨

테스트 파일은 테스트 하려는 클래스와 가까운 위치에 두고, .spec, .test 접미사를 가짐

기본적으로 테스트에 의존성 주입을 적용하지는 않음

• 격리된 테스트 환경

Test 클래스를 통해 mocking 한 애플리케이션 실행 컨텍스트 제공

• @Module() 데코레이터에 전달하는 모듈 메타데이터 객체를 인수

• 모듈과 그 의존성을 부트스트랩

  • get() 메서드를 사용하여 선언된 정적 인스턴스를 검색
  • resolve() 메서드를 사용하여 범위가 지정된 프로바이더(일시적 또는 요청 범위)를 동적으로 해결

• 실제 provider 가 아닌 custom provider 로 대체 가능

재사용 가능한 논리적 부분을 개발하여 여러 유형에서 사용

• Express/Fastify
• Http/WebSocket/Micro
• etc

한 번 빌드해서 어디서나 사용하게 하는 걸 목표로 함

• 중요한 라이프사이클 이벤트에 대한 가시성을 제공
• 이벤트가 발생할 때 모듈, providers 또는 컨트롤러에서 등록된 코드를 실행

애플리케이션 bootstrap 및 종료 동안 발생

• 각 라이플사이클 이벤트에서 등록된 라이프사이클 훅 메서드 호출

• app.close()를 명시적으로 호출
• 프로세스가 특별한 시스템 신호(예: SIGTERM)를 받을 때만 트리거
• 애플리케이션 부트스트랩 시 enableShutdownHooks를 올바르게 호출

• 이러한 이벤트의 경우, app.close()를 명시적으로 호출하지 않으면 시스템 신호(Such as SIGTERM)와 함께 작동하도록 선택

라이프사이클 훅을 사용하기 위해 typescript 의 interface 를 활용 훅에 async/await 적용 가능 대체로 종료 관련 훅은 컨테이너 수명을 관리하기 위해 적용

• 이 경우 시스템 리소스를 사용학 ㅔ됌

1. ArgumentHost 핸들러에 전달되는 인수를 검색하는 메서드 제공

   • host 매개변수로 참조

   단순히 핸들러의 인수에 대한 추상화를 제공

2. ExecutionContext ArgumentsHost를 확장하여 현재 실행 프로세스에 대한 추가 세부 정보를 제공

   • 대체로 핸들러 자체와 클래스 자체에 대한 정보 반환
   • Refelction 사용자 정의 메타데이터 생성 및 엑세스 가능 여러 레벨에서 메타데이터를 제공할 수 있으므로, 이를 추출하고 병합할 수 있는 내부 함수가 있음
   • MetaData 내장된 @SetMetadata() 로 메타데이터 접근 가능

• 특정 서버리스 함수 호출에 필요한 모듈만 로드하여 부트스트랩 시간을 단축

lazyModule 임을 명시하여 지연 로딩 처리 가능

• class 내에서

  import { Injectable, LazyModuleLoader } from '@nestjs/common';
  

@Injectable() export class CatsService { constructor(private lazyModuleLoader: LazyModuleLoader) {} }

- app 인스턴스에서
```typescript
const lazyModuleLoader = app.get(LazyModuleLoader);

lazymoduleloader 의 load() 를 통해 얻은 moduleRef 클래스로 접근 가능

const { LazyModule } = await import('./lazy.module');
const moduleRef = await this.lazyModuleLoader.load(() => LazyModule);

const { LazyService } = await import('./lazy.service');
const lazyService = moduleRef.get(LazyService);

Controller 는 지연 로딩 대상이 될 수 없음

1. 내부 provider 목록을 탐색 get() 메서드를 통해 현재 모듈에 존재하는 provider, controller 또는 injectable 을 주입 토큰/클래스 이름을 사용하여 검색

• global 컨텍스트에서 검색하려면 strict 속성을 false 로 넘겨줘야 함

2. 주입 토큰을 조회 키로 사용하여 모든 provider에 대한 참조를 얻을 수 있음

3. 정적 및 스코프가 지정된 provider를 동적으로 인스턴스화할 수 있는 방법도 제공

• provider의 주입 토큰을 인수로 전달하여 resolve() 메서드

  • DI 컨테이너 서브 트리에서 provider의 고유한 인스턴스를 반환

• ContextIdFactory 클래스를 사용하여 컨텍스트 식별자를 생성해 전달하면 여러 resolve() 의 호출에도 동일한 인스턴스를 사용할 수 있음

  • 수동으로 생성된 context 는 Nest DI 에 자동으로 관리되지 않음

• 현재 컨텍스트 식별자를 얻으려면 @Inject() 데코레이터를 사용하여 요청 객체를 주입

• create() 를 통해 동적으로 인스턴스화 해, 프레임워크 컨테이너 외부에서 다양한 클래스를 조건부로 인스턴스화

• 모듈 과 provider 간에 발생할 수 있음

1. forward referencing을 사용하는 방법 forwardRef() 함수를 통해 정의되지 않은 클래스에 접근 가능

• @Inject()와 forwardRef() 를 사용하여 순환 종속성을 해결
• 인스턴스화 순서는 불확정적이므로 코드가 어느 생성자가 먼저 호출되는지에 의존하지 않아야 함

2. ModuleRef 클래스를 사용하여 DI 컨테이너에서 provider 인스턴스를 검색하는 방법

• module 에서 forwardRef() 를 사용해 참조

• 각 요청이 별도의 스레드에 의해 처리되는 요청/응답 멀티 스레드 무상태 모델을 따르지 않음
• 싱글톤 인스턴스 사용에 무리가 없음

@Injectable() 데코레이터에 scope 속성을 전달해 정의 가능

• custom provider 에서도 마찬가지

2. REQUEST Scope

자체적으로 요청 스코프

• 의존성 여부에 따라 스코프가 전달될 수 있음

• 성능에 굉장한 영향을 미침

  • Durable provider 를 통해 매 요청에 따른 생성 해결 durable 속성을 전달해야 하며, 요청에 상응하는 하위 구조에 전략을 구현해야 함

3. TRANSIENT Scope 요청에 따른 새로운 인스턴스를 반환받기 때문에 전달되거나 종속되지 않음

INQUIRER 토큰을 주입해 provider 가 생성된 클래스를 알 수 있음

• 동작 모듈은 플러그인 개념

런타임에 생성된 모듈로, module이라는 추가 속성만 가짐

• 다른 속성은 필수가 아닐 수 있으나 module 속성은 필수

@Module({})
export class ConfigModule {
  static register(): DynamicModule {
    return {
      module: ConfigModule,
      providers: [ConfigService],
      exports: [ConfigService],
    };
  }
}

직접 생성이 어려우므로 ConfigurableModuleBuilder 제공

{
  provide: 'ASYNC_CONNECTION',
  useFactory: async () => {
    const connection = await createConnection(options);
    return connection;
  },
}

• provider를 주입하는 클래스의 인스턴스를 생성하기 전에 promise의 해결을 기다림

providers 에서 IoC 하는 과정은 실제로 구체적으로 보면 이렇게 됌

• 토큰(service 클래스 명) 과 실제 클래스를 연결하는 것

기본 provider 의 기능 범위를 넘어서는 일에 custom provider 동작

• Nest가 클래스를 인스턴스화하는 대신 사용자 정의 인스턴스를 만들고 싶을 때
• 기존 클래스를 두 번째 의존성에서 재사용하고 싶을 때
• 테스트를 위해 클래스를 모의 버전으로 재정의하고 싶을 때

1. useValue

• 상수 값을 주입하거나 외부 라이브러리를 Nest 컨테이너에 넣거나 실제 구현을 모의 객체로 교체하는 데 유용

import { CatsService } from './cats.service';

const mockCatsService = {
  /* mock implementation
  ...
  */
};

@Module({
  imports: [CatsModule],
  providers: [
    {
      provide: CatsService,
      useValue: mockCatsService,
    },
  ],
})
export class AppModule {}

• DI 토큰으로 문자열이나 심볼을 사용하는 유연성

  import { connection } from './connection';
  

@Module({ providers: [ { provide: 'CONNECTION', useValue: connection, }, ], }) export class AppModule {}

- `Inject()` 데코레이터로 주입 가능
```typescript
@Injectable()
export class CatsRepository {
  constructor(@Inject('CONNECTION') connection: Connection) {}
}

2. useClass

토큰이 해결해야 하는 클래스를 동적으로 결정

const configServiceProvider = {
  provide: ConfigService,
  useClass:
    process.env.NODE_ENV === 'development'
      ? DevelopmentConfigService
      : ProductionConfigService,
};

@Module({
  providers: [configServiceProvider],
})
export class AppModule {}

• 여기서는 다시 또 class 이름을 토큰으로 사용

3. useFactory 제공자를 동적으로 생성

• 팩토리 함수에서 반환된 값에 의해 제공

  const connectionProvider = {
  provide: 'CONNECTION',
  useFactory: (optionsProvider: OptionsProvider, optionalProvider?: string) => {
    const options = optionsProvider.get();
    return new DatabaseConnection(options);
  },
  inject: [OptionsProvider, { token: 'SomeOptionalProvider', optional: true }],
  };
  

@Module({ providers: [ connectionProvider, OptionsProvider, ], }) export class AppModule {}

4. `useExisting`
기존 제공자에 대한 별칭
```typescript
@Injectable()
class LoggerService {
  /* implementation details */
}

const loggerAliasProvider = {
  provide: 'AliasedLoggerService',
  useExisting: LoggerService,
};

@Module({
  providers: [LoggerService, loggerAliasProvider],
})
export class AppModule {}

서비스가 아닌 모든 기능 을 provider 로 처리할 수 있음

• 환경 구성 등

  const configFactory = {
  provide: 'CONFIG',
  useFactory: () => {
    return process.env.NODE_ENV === 'development' ? devConfig : prodConfig;
  },
  };
  

@Module({ providers: [configFactory], }) export class AppModule {}

export 는 token 이나 provider 객체 자체로도 가능

ES2016 데코레이터는 함수(타겟, 이름, 속성 기술자)를 인수로 받아서 반환하는 표현식입니다. 데코레이터 앞에 @ 문자를 붙이고 데코레이터할 대상의 맨 위에 배치하여 적용합니다. 데코레이터는 클래스, 메서드 또는 속성에 대해 정의될 수 있습니다.

이러한 기본 구조:

export const Test = createParamDecorator(
  (data: string, ctx: ExecutionContext) => {
    const request = ctx.switchToHttp().getRequest();
    const user = request.user;

    return data ? user?.[data] : user;
  },
);

데코레이터에 값을 넘겨주면서 실제 data 에 접근한 로직 구현 가능

커스텀 파라미터 decorator 도 내장된 decorator 와 동일하게 취급

@Get()
async findOne(
  // 해당 옵션 필수
  @User(new ValidationPipe({ validateCustomDecorators: true }))
  user: UserEntity,
) {
  console.log(user);
}

• custom annotated parameters 에 대해서도 실행
• 커스텀 데코레이터에 직접 적용

데코레이터들끼리 조합도 가능

NestInterceptor 인터페이스를 구현해야 함

AOP 에 영향을 받아

• 메서드 실행 전/후에 추가 로직 바인딩
• 함수에서 반환된 결과 변환
• 함수에서 발생한 예외 변환
• 기본 함수 동작 확장
• 특정 조건에 따라 함수를 완전히 재정의 (예: 캐싱 목적)

두 가지 인수를 받는데:

1. ArgumentHost 를 상속하는 ExecutionContext
2. handle() 함수를 구현하는 CallHandler 인터페이스

• 원하는 시점에 라우트 핸들러 함수 호출
• 호출하지 않으면 라우트 핸들러 전혀 실행되지 않음 즉, 라우트 핸들러 실행 전/후 에 원하는 로직 구현 가능
• Pointcut 이라고도 하며
• RxJS 연산자의 Observable를 통해 응답 조작 가능

전체에 걸쳐 발생하는 요구 사항에 대한 재사용 가능한 솔루션 만드는 용도

생각외로 RxJS 연산자가 많이 사용되므로 고려

단일 책임 원칙 인증

• 특정 조건(권한, 역할, ACL 등)에 따라 주어진 요청이 라우트 핸들러에 의한 처리 여부를 결정

인증/권한은 전통적인 Express 애플리케이션에서 종종 미들웨어에 의해 처리

• 토큰 유효성 검사나 request 객체에 속성을 첨부하는 작업은 특정 라우트 컨텍스트(및 메타데이터)와 강하게 연결되지 않기 때문
• 미들웨어는 본질적으로 어떤 핸들러가 next() 함수 호출 후에 실행될지 알 수 없음 반면, Guard는 ExecutionContext 인스턴스에 접근하여 이후 실행 대상 확인 가능

예외 필터, 파이프, 인터셉터와 마찬가지로 요청/응답 사이클의 정확한 지점에서 처리 로직을 삽입하도록 설계, 선언적으로 수행 가능

가드는 모든 미들웨어가 실행된 후, 인터셉터나 파이프가 실행되기 전에 실행

Authorization guard

충분한 권한을 가지고 있을 때만 사용하는 경우

• 예시로, 토큰 추출, 유효성 검사, 요청이 진행될 수 있는지 여부를 결정

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { Observable } from 'rxjs';

@Injectable()
export class AuthGuard implements CanActivate {
  canActivate(
    context: ExecutionContext,
  ): boolean | Promise<boolean> | Observable<boolean> {
    const request = context.switchToHttp().getRequest();
    return validateRequest(request);
  }
}

• validateRequest 는 커스텀 함수

모든 가드는 canActivate() 함수를 구현해야 함

• 현재 요청이 허용되는지 여부를 나타내는 boolean 값 반환

• 이는 동기적으로 또는 비동기적으로(Promise 또는 Observable을 통해) 응답 반환

  • true를 반환하면 요청이 처리
  • false를 반환하면 Nest는 요청을 거부

Execution context

canActivate() 함수는 단일 인수로 ExecutionContext 인스턴스 받음ExecutionContext는 ArgumentsHost를 상속

• exception filters 장의 Arguments host 섹션

ArgumentsHost를 확장해 ExecutionContext는 현재 실행 프로세스에 대한 추가 세부 정보를 제공하는 여러 새로운 헬퍼 메서드를 추가

• 다양한 컨트롤러, 메서드 및 실행 컨텍스트에서 동작하게 함

여기

Role-based authentication

모든 역할 허용에서 특정 역할 허용 예시:

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { Observable } from 'rxjs';

@Injectable()
export class RolesGuard implements CanActivate {
  canActivate(
    context: ExecutionContext,
  ): boolean | Promise<boolean> | Observable<boolean> {
    return true;
  }
}

Binding guards

컨트롤러 범위, 메서드 범위 또는 전역 범위로 설정 가능

• @UseGuards() 데코레이터를 사용하여 컨트롤러 범위 가드를 설정
• 단일-복수 인수 목록을 받음

@Controller('cats')
@UseGuards(RolesGuard)
export class CatsController {}

인스턴스가 아닌 클래스로 전달하여 프레임워크가 인스턴스화를 책임지도록 하고 의존성 주입을 활성화:

@Controller('cats')
@UseGuards(new RolesGuard())
export class CatsController {}

단일 메서드에 적용시 메서드 수준에서 @UseGuards() 데코레이터를 적용

전역 가드는 Nest 애플리케이션 인스턴스의 useGlobalGuards() 메서드를 사용:

const app = await NestFactory.create(AppModule);
app.useGlobalGuards(new RolesGuard());

의존성 주입 측면에서 전역 가드는 모듈 외부에서 등록될 경우(위 예제에서처럼 useGlobalGuards()를 사용하여) 의존성을 주입할 수 없음

모듈 내부에서 직접 전역 가드를 설정:

import { Module } from '@nestjs/common';
import { APP_GUARD } from '@nestjs/core';

@Module({
  providers: [
    {
      provide: APP_GUARD,
      useClass: RolesGuard,
    },
  ],
})
export class AppModule {}

Setting roles per handler

역할이나 각 핸들러에 대해 허용되는 역할에 대해 알지 못하는 단순한 상태 커스텀 메타데이터로 해결

• 여기

Reflector.createDecorator 정적 메서드, 생성된 데코레이터나 내장된 @SetMetadata() 데코레이터를 통해, 라우트 핸들러에 커스텀 메타데이터를 첨부 가능

• Reflector는 프레임워크에 의해 제공되며 @nestjs/core 패키지

import { Reflector } from '@nestjs/core';

export const Roles = Reflector.createDecorator<string[]>();

• Roles 데코레이터는 string[] 타입의 단일 인수를 받는 함수

이제 이 데코레이터를 사용하려면 핸들러에 주석을 추가하기만 하면 됩니다:

@Post()
@Roles(['admin'])
async create(@Body() createCatDto: CreateCatDto) {
  this.catsService.create(createCatDto

);
}

Reflector.createDecorator 메서드를 사용하는 대신 내장된 @SetMetadata() 데코레이터를 사용할 수 있습니다. 자세한 내용은 여기를 참조하세요.

Putting it all together

현재 처리 중인 라우트의 실제 역할과 현재 사용자에게 할당된 역할을 비교하여 조건부 처리:

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { Reflector } from '@nestjs/core';
import { Roles } from './roles.decorator';

@Injectable()
export class RolesGuard implements CanActivate {
  constructor(private reflector: Reflector) {}

  canActivate(context: ExecutionContext): boolean {
    const roles = this.reflector.get(Roles, context.getHandler());
    if (!roles) {
      return true;
    }
    const request = context.switchToHttp().getRequest();
    const user = request.user;
    return matchRoles(roles, user.roles);
  }
}

Reflection and metadata 섹션에서 Reflector를 컨텍스트에 맞게 사용하는 방법에 대해 자세히 알아보세요.

권한이 부족한 경우라면:

{
  "statusCode": 403,
  "message": "Forbidden resource",
  "error": "Forbidden"
}

• false를 반환하면 프레임워크는 ForbiddenException 을 기본 반환

특정 예외:

throw new UnauthorizedException();

가드에서 발생한 모든 예외는 예외 레이어에 의해 처리

실제 예제에 대해 자세히 알아보려면 여기를 참조하세요.

파이프는 두 가지 주요 용도로 사용

• 변환: 입력 데이터를 원하는 형태로 변환 (예: 문자열->정수)
• 검증: 입력 데이터를 평가하고 유효하면 그대로 통과시키고, 그렇지 않으면 예외를 던짐

두 경우 모두 파이프는 컨트롤러 라우트 핸들러에서 처리되는 arguments에 대해 작동

• 메서드가 호출되기 직전에 파이프를 삽입
• 이후 변환된 인자가 있는 상태로 라우트 핸들러가 호출

파이프는 예외 구역 내에서 실행됩니다. 즉, 파이프가 예외를 던지면 예외 레이어(전역 예외 필터 및 현재 컨텍스트에 적용된 모든 예외 필터에 의해 처리됩니다. 따라서 파이프에서 예외가 발생하면 컨트롤러 메서드는 실행되지 않습니다. 이는 외부 소스에서 애플리케이션으로 들어오는 데이터를 유효성 검사하는 최선의 방법을 제공합니다.

Built-in pipes

Nest에는 기본적으로 사용할 수 있는 아홉 가지 파이프가 있습니다:

• ValidationPipe
• ParseIntPipe
• ParseFloatPipe
• ParseBoolPipe
• ParseArrayPipe
• ParseUUIDPipe
• ParseEnumPipe
• DefaultValuePipe
• ParseFilePipe

이 파이프들은 @nestjs/common 패키지에서 사용

Binding pipes

파이프 인스턴스를 적절한 컨텍스트에 바인딩해야 사용 가능

@Get(':id')
async findOne(@Param('id', ParseIntPipe) id: number) {
  return this.catsService.findOne(id);
}

• 매개 변수가 숫자여야 하고, 메서드 실행 전에 호출

다음의 호출에

GET localhost:3000/abc

다음의 예외가 발생

{
  "statusCode": 400,
  "message": "Validation failed (numeric string is expected)",
  "error": "Bad Request"
}

마찬가지로, 클래스를 전달하면 프레임워크가 인스턴스화 책임을 지고 의존성 주입을 활성화

• 혹은, 파이프와 가드는 인라인 인스턴스를 전달 가능
• 인라인 인스턴스를 전달하면 내장된 파이프의 동작을 옵션을 통해 커스터마이징 가능

@Get(':id')
async findOne(
  @Param('id', new ParseIntPipe({ errorHttpStatusCode: HttpStatus.NOT_ACCEPTABLE }))
  id: number,
) {
  return this.catsService.findOne(id);
}

ParseUUIDPipe()를 사용할 때 버전 3, 4 또는 5의 UUID를 파싱합니다. 특정 버전의 UUID만 필요하다면 파이프 옵션에 버전을 전달할 수 있습니다.

유효성 검사 기술에서 검증 파이프의 광범위한 예제를 참조하세요.

Custom pipes

import { PipeTransform, Injectable, ArgumentMetadata } from '@nestjs/common';

@Injectable()
export class ValidationPipe implements PipeTransform {
  transform(value: any, metadata: ArgumentMetadata) {
    return value;
  }
}

PipeTransform<T, R>는 모든 파이프가 구현해야 하는 제네릭 인터페이스입니다. 제네릭 인터페이스는 입력 value의 타입을 나타내는 T와 transform() 메서드의 반환 타입을 나타내는 R을 사용합니다.

모든 파이프는 PipeTransform 를 위해 transform() 메서드를 구현해야 함

• value
  • 현재 처리 중인 메서드 인자(라우트 핸들러 메서드가 받기 전의 인자)
• metadata
  • 현재 처리 중인 메서드 인자의 메타데이터

export interface ArgumentMetadata {
  type: 'body' | 'query' | 'param' | 'custom';
  metatype?: Type<unknown>;
  data?: string;
}

• 이 속성들은 현재 처리 중인 인자를 설명

TypeScript 인터페이스는 트랜스파일 동안 사라집니다. 따라서 메서드 매개변수의 타입이 클래스가 아닌 인터페이스로 선언되면 metatype 값은 Object가 됩니다.

Schema based validation

post 의 body 객체에 대한 확인 예제;

@Post()
async create(@Body() createCatDto: CreateCatDto) {
  this.catsService.create(createCatDto);
}

export class CreateCatDto {
  name: string;
  age: number;
  breed: string;
}

create 메서드 요청이 유효한 본문을 포함하고 있는지 확인하려면, dto 객체의 세 가지 멤버를 검증

• 라우트 핸들러 메서드 내부에서 수행 시 단일 책임 원칙(SRP) 불충족

따라서, 검증 클래스를 작성 후 검증 작업을 위임

• 각 메서드의 시작 부분에서 호출해야 한다는 단점

혹은, 검증 미들웨어

• 실행 컨텍스트(호출될 핸들러 및 해당 매개변수를 포함하는)를 인식하지 못하는 미들웨어의 특성상 일반적인 미들웨어를 작성할 수 없

Object schema validation

깔끔하고 DRY 방식으로 수행하는 여러 접근 방식 중, 스키마 기반 검증이 일반적

Zod 라이브러리는 간단한 API로 스키마를 작성할 수 있

$ npm install --save zod

• schema.parse() 메서드를 적용하여 제공된 스키마에 대해 들어오는 인수를 검증

앞서 언급했듯이, 검증 파이프는 값을 변경하지 않고 반환하거나 예외를 던짐

import { PipeTransform, ArgumentMetadata, BadRequestException } from '@nestjs/common';
import { ZodSchema  } from 'zod';

export class ZodValidationPipe implements PipeTransform {
  constructor(private schema: ZodSchema) {}

  transform(value: unknown, metadata: ArgumentMetadata) {
    try {
      const parsedValue = this.schema.parse(value);
      return parsedValue;
    } catch (error) {
      throw new BadRequestException('Validation failed');
    }
  }
}

Binding validation pipes

ZodValidationPipe를 사용 단계:

1. ZodValidationPipe 인스턴스를 생성
2. 파이프의 클래스 생성자에 컨텍스트별 Zod 스키마를 전달
3. 파이프를 메서드에 바인딩

• Zod 스키마 예제:

import { z } from 'zod';

export const createCatSchema = z
  .object({
    name: z.string(),
    age: z.number(),
    breed: z.string(),
  })
  .required();

export type CreateCatDto = z.infer<typeof createCatSchema>;

@UsePipes() 데코레이터의 구현:

@Post()
@UsePipes(new ZodValidationPipe(createCatSchema))
async create(@Body() createCatDto: CreateCatDto) {
  this.catsService.create(createCatDto);
}

@UsePipes() 데코레이터는 @nestjs/common 패키지에서 가져옵니다.

zod 라이브러리는 tsconfig.json 파일에서 strictNullChecks 구성을 활성화해야 합니다.

Class validator

이 섹션의 기술은 TypeScript를 필요로 하며 바닐라 JavaScript로 작성된 애플리케이션에서는 사용할 수 없습니다.

class-validator 라이브러리와 잘 작동

• 데코레이터 기반 검증 가능
• metatype에 접근할 수 있기에 Pipe 기능과 결합할 때 매우 강력

$ npm i --save class-validator class-transformer

CreateCatDto 클래스가 Post 본문 객체의 단일 진리의 원천으로 유지(별도의 검증 클래스를 작성할 필요가 없음)

import { IsString, IsInt } from 'class-validator';

export class CreateCatDto {
  @IsString()
  name: string;

  @IsInt()
  age: number;

  @IsString()
  breed: string;
}

class-validator 데코레이터에 대해 자세히 알아보려면 여기를 참조하세요.

ValidationPipe 클래스를 작성

import { PipeTransform, Injectable, ArgumentMetadata, BadRequestException } from '@nestjs/common';
import { validate } from 'class-validator';
import { plainToInstance } from 'class-transformer';

@Injectable()
export class ValidationPipe implements PipeTransform<any> {
  async transform(value: any, { metatype }: ArgumentMetadata) {
    if (!metatype || !this.toValidate(metatype)) {
      return value;
    }
    const object = plainToInstance(metatype, value);
    const errors = await validate(object);
    if (errors.length > 0) {
      throw new BadRequestException('Validation failed');
    }
    return value;
  }

  private toValidate(metatype: Function): boolean {
    const types: Function[] = [String, Boolean, Number, Array, Object];
    return !types.includes(metatype);
  }
}

직접 일반적인 검증 파이프를 작성할 필요는 없습니다. Nest는 기본적으로 ValidationPipe를 제공합니다. 내장된 ValidationPipe는 우리가 작성한 샘플보다 더 많은 옵션을 제공하며, 자세한 내용과 많은 예제를 여기에서 확인할 수 있습니다.

위에서는 class-transformer 라이브러리를 사용했습니다. 이 라이브러리는 class-validator 라이브러리와 같은 저자가 작성했기 때문에 상호 호환성이 좋습니다.

1. transform() 메서드가 async

• 동기 및 비동기 파이프가 가능하므로 async를 활용
• 일부 class-validator 검증이 비동기일 수 있기 때문(Promise를 활용)

2. 구조 분해 할당으로 ArgumentMetadata에서 metatype 필드 추출

3. 헬퍼 함수 toValidate()

• 기본 JavaScript 타입은 검증 단계 생략(기본 JavaScript 타입에는 검증 데코레이터를 붙일 수 없기 때문)

4. 일반 JavaScript 인수 객체를 plainToInstance() 함수로 타입이 지정된 객체로 변환하여 검증을 수행

• 네트워크 요청에서 역직렬화된 들어오는 post 본문 객체는 타입 정보가 전혀 없음 (Express와 같은 기본 플랫폼의 작동 방식)
• class-validator는 우리가 DTO에 대해 이전에 정의한 검증 데코레이터를 사용해야 하므로, 들어오는 본문을 단순한 객체가 아닌 적절한 데코레이터가 적용된 객체로 처리하기 위해 이 변환이 필요

5. 검증 파이프는 값을 변경하지 않고 반환하거나 예외를 던

6. ValidationPipe를 바인딩

• 매개변수 범위, 메서드 범위, 컨트롤러 범위 또는 전역 범위로 바인딩

파이프 인스턴스를 라우트 핸들러 @Body() 데코레이터에 바인딩하여 파이프가 post 본문을 검증하게 함

@Post()
async create(
  @Body(new ValidationPipe()) createCatDto: CreateCatDto,
) {
  this.catsService.create(createCatDto);
}

Global scoped pipes

전역 범위 파이프로 설정하여 애플리케이션 전체의 모든 라우트 핸들러에 적용 가능

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalPipes(new ValidationPipe());
  await app.listen(3000);
}
bootstrap();

하이브리드 앱의 경우 useGlobalPipes() 메서드는 게이트웨이 및 마이크로서비스에 대해 파이프를 설정하지 않습니다. "표준" (비하이브리드) 마이크로서비스 앱의 경우, useGlobalPipes()는 파이프를 전역적으로 마운트합니다.

• 전역 파이프는 전체 애플리케이션에 대해 모든 컨트롤러 및 모든 라우트 핸들러에 사용

전역 파이프가 모듈 외부에서 등록될 경우(위 예제에서처럼 useGlobalPipes()를 사용하여) 의존성을 주입할 수 없음

• 모듈의 컨텍스트 외부에서 이루어졌기 때문

모듈 내부에서 직접 전역 파이프를 설정하여 해결 가능:

import { Module } from '@nestjs/common';
import { APP_PIPE } from '@nestjs/core';

@Module({
  providers: [
    {
      provide: APP_PIPE,
      useClass: ValidationPipe,
    },
  ],
})
export class AppModule {}

이 방법을 사용하여 파이프에 대해 의존성 주입을 수행할 때, 이 구성이 사용된 모듈에 관계없이 파이프는 실제로 전역적임을 유의하세요. 어디에서 해야 할까요? 파이프(위 예제에서는 ValidationPipe)가 정의된 모듈을 선택하세요. 또한, useClass는 커스텀 제공자 등록을 처리하는 유일한 방법이 아닙니다. 자세한 내용은 여기에서 확인하세요.

The built-in ValidationPipe

직접 일반적인 검증 파이프를 작성할 필요는 없고,ValidationPipe를 제공 내장된 ValidationPipe는 우리가 작성한 샘플보다 더 많은 옵션을 제공하며, 자세한 내용과 많은 예제를 여기에서 확인 가능

Transformation use case

입력 데이터를 원하는 형식으로 변환도 가능 transform 함수에서 반환된 값이 인자의 이전 값을 완전히 덮어쓰므로 가능

변환 파이프는 타입 변환 혹은 기본값 적용 등의 작업을 수행하여 클라이언트 요청과 요청 핸들러 사이에 처리 함수를 삽입 가능

import { PipeTransform, Injectable, ArgumentMetadata, BadRequestException } from '@nestjs/common';

@Injectable()
export class ParseIntPipe implements PipeTransform<string, number> {
  transform(value: string, metadata: ArgumentMetadata): number {
    const val = parseInt(value, 10);
    if (isNaN(val)) {
      throw new BadRequestException('Validation failed');
    }
    return val;
  }
}

바인딩은:

@Get(':id')
async findOne(@Param('id', new ParseIntPipe()) id) {
  return this.catsService.findOne(id);
}

Providing defaults

Parse* 파이프는 매개변수 값이 정의되어 있을 것으로 예상(기대)

• null 또는 undefined 값은 예외
• 누락의 경우를 처리하려면 Parse* 파이프가 이러한 값에 대해 작동하기 전에 기본 값을 제공

DefaultValuePipe를 사용하여, Parse* 파이프가 작동하기 전에 @Query() 데코레이터에서 DefaultValuePipe 인스턴스를 인스턴스:

@Get()
async findAll(
  @Query('activeOnly', new DefaultValuePipe(false), ParseBoolPipe) activeOnly: boolean,
  @Query('page', new DefaultValuePipe(0), ParseIntPipe) page: number,
) {
  return this.catsService.findAll({ activeOnly, page });
}

• 모든 예외에 적용
• 다뤄지지 않은 예외는 해당 레이어로 가며, 사용자 친화적인 메시지 응답

HttpException 을 내장된 전역 예외 처리 필터에서 처리됨

• 해당되는 예외 혹은 하위 예외가 아닐 경우 unrecognized 로 해당 응답 반환

  {
  "statusCode": 500,
  "message": "Internal server error"
  }

  전역 예외 필터는 http-errors 라이브러리를 부분적으로 지원합니다. statusCode 와 message 를 포함한 에러는 적절하게 합쳐지고 응답(확인되지 않은 InternalServerErrorException 예외 대신에)으로써 반환됩니다

Thorwing standard exceptions

내장된 @nestjs/common 패키지에서 비롯된 HttpException 클래스를 제공

• 특정 HTTP Rest/GraphQL API 에 대해 표준 HTTP 응답을 반환하는 것이 바람직

@Get()
async findAll() {
  throw new HttpException('Forbidden', HttpStatus.FORBIDDEN);
}

@nestjs/common 패키지에서 비롯된 helper enum 입니다.

• 이것에 대해

  {
  "statusCode": 403,
  "message": "Forbidden"
  }

  HttpException 생성자는 response 와 status 라는 두 가지 인자를 받음

• response 은 JSON 응답 본문이며, string 혹은 object 가능

  • object 를 넘겨서 JSON 응답 본문 대체 가능
  • statusCode 은 HTTP status code
  • message는 HTTP error 에 대한 짧은 설명
    • response 에 문자열을 넘김으로써 대체 가능

• status 는 HTTP Status Code 를 의미

  • 올바른 HTTP Status code 가 들어와야하며, @nestjs/common 의 HttpStatus enum 을 쓰는게 제일 바람직

• error의 이유 에 해당하는 options 속성은 응답 객체에 들어가진 않으나, 로깅에 매우 유용

  • HttpException 가 발생한 내부 사유 확인 가능

@Get()
async findAll() {
  try {
    await this.service.findAll()
  } catch (error) {
    throw new HttpException({
      status: HttpStatus.FORBIDDEN,
      error: 'This is a custom message',
    }, HttpStatus.FORBIDDEN, {
      cause: error
    });
  }
}

• error 반환이며

  {
  "status": 403,
  "error": "This is a custom message"
  }

• 그에 대한 응답

Custom exceptions

HttpException 을 상속하는 개인화된 예외 계층 만들기

export class ForbiddenException extends HttpException {
  constructor() {
    super('Forbidden', HttpStatus.FORBIDDEN);
  }
}

@Get()
async findAll() {
  throw new ForbiddenException();
}

일반적인 예외 처리와 동일하게 적용

Built-in HTTP exceptions

HttpException 으로부터 상속받고, @nestjs/common 패키지에 비롯

Exception filters

예외 계층에 대한 완전한 컨트롤

• 사용자에게 반환될 응답의 내용과 예외 flow 에 대해 컨트롤 가능

import { ExceptionFilter, Catch, ArgumentsHost, HttpException } from '@nestjs/common';
import { Request, Response } from 'express';

@Catch(HttpException)
export class HttpExceptionFilter implements ExceptionFilter {
  catch(exception: HttpException, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse<Response>();
    const request = ctx.getRequest<Request>();
    const status = exception.getStatus();

    response
      .status(status)
      .json({
        statusCode: status,
        timestamp: new Date().toISOString(),
        path: request.url,
      });
  }
}

모든 예외 필터는 일반 ExceptionFilter<T> 인터페이스를 구현해야 합니다. 이를 위해서는 catch(exception: T, host: ArgumentsHost) 함수에 표시된 서명을 제공해야 합니다 . T는 예외 유형을 나타냅니다. @nestjs/platform-fastify 를 사용하는 경우 response.json() 대신에 response.send() 를 사용할 수 있습니다. fastify를 위해 정확한 타입을 가져오는 걸 명심하세요

@Catch(HttpException) 데코레이터는 HttpException에 해당하는 특정 예외만 본다는 얘기

• 단일-복수 파라미터 가능

Arguments host

catch() 함수의 인자

• exception 은 현재 진행 중인 예외 객체
• host 는 ArgumentsHost 객체
  • execution context

Nest 모든 context 에 있기 때문에 추상화 수준 필요했음

Binding filters

@Post()
@UseFilters(new HttpExceptionFilter())
async create(@Body() createCatDto: CreateCatDto) {
  throw new ForbiddenException();
}

@UseFilters() 데코레이터는 @nestjs/common 패키지에 있습니다.

• 단일-복수 filter 인스턴스를 인자로 받음
• 인스턴스가 아닌 클래스 자체를 넘겨, IoC 및 DI 가능

가능할 경우 인스턴스보다 클래스를 통해 필터를 적용허세요. 동일한 클래스의 인스턴스를 재사용할 수 있어 메모리 사용량이 줄어듭니다.

함수 레벨, 컨트롤러 레벨, 전역 레벨 에서 스코핑 가능

// 컨트롤러 레벨
@UseFilters(new HttpExceptionFilter())
export class CatsController {}

// 전역 레벨
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalFilters(new HttpExceptionFilter());
  await app.listen(3000);
}
bootstrap();

useGlobalFilters() 함수는 게이트웨이 나 하이브리드 앱에는 적용되지 않습니다.

useGlobalFilters() 를 사용하는 경우 DI 를 적용할 수 없음

• 어느 module의 context 외부에서 수행되기 때문

// DI 문제를 해결한 방식

import { Module } from '@nestjs/common';
import { APP_FILTER } from '@nestjs/core';

@Module({
  providers: [
    {
      provide: APP_FILTER,
      useClass: HttpExceptionFilter,
    },
  ],
})
export class AppModule {}

DI 문제를 해결한 방식은 모듈에 상관없이 필터는 전역적입니다. 필터가 적용된 모듈을 선택하세요. 그리고, useClass 만이 커스텀 provider 를 등록하는 방법은 아닙니다. 여기

Catch everything

• @Catch() 에 변수를 주지 않으면 됌

import {
  ExceptionFilter,
  Catch,
  ArgumentsHost,
  HttpException,
  HttpStatus,
} from '@nestjs/common';
import { HttpAdapterHost } from '@nestjs/core';

@Catch()
export class AllExceptionsFilter implements ExceptionFilter {
  constructor(private readonly httpAdapterHost: HttpAdapterHost) {}

  catch(exception: unknown, host: ArgumentsHost): void {
    // In certain situations `httpAdapter` might not be available in the
    // constructor method, thus we should resolve it here.
    const { httpAdapter } = this.httpAdapterHost;

    const ctx = host.switchToHttp();

    const httpStatus =
      exception instanceof HttpException
        ? exception.getStatus()
        : HttpStatus.INTERNAL_SERVER_ERROR;

    const responseBody = {
      statusCode: httpStatus,
      timestamp: new Date().toISOString(),
      path: httpAdapter.getRequestUrl(ctx.getRequest()),
    };

    httpAdapter.reply(ctx.getResponse(), responseBody, httpStatus);
  }
}

• 플랫폼에 특정화된 객체를 쓰지 않고, HTTP adapter 를 통해 플랫폼-친화적 응답 전달

모든 것을 포착하는 예외 필터와 특정 유형에 바인딩된 필터를 결합할 때 특정 필터가 바인딩된 유형을 올바르게 처리할 수 있도록 "Catch everything" 필터를 먼저 선언해야 합니다.

Inheritance

내장된 전역 예외 필터 를 확장해 재정의 하고 싶은 경우

import { Catch, ArgumentsHost } from '@nestjs/common';
import { BaseExceptionFilter } from '@nestjs/core';

@Catch()
export class AllExceptionsFilter extends BaseExceptionFilter {
  catch(exception: unknown, host: ArgumentsHost) {
    super.catch(exception, host);
  }
}

BaseExceptionFilter 를 확장하는 함수-레벨, 컨트롤러-레벨 필터는 new 로 인스턴스화 하면 안됩니다. 대신에, 프레임워크가 자동으로 인스턴스화 하게 하세요.

전역 필터는 기본 필터를 확장할 수 있음

1. HttpAdapter 주입

   async function bootstrap() {
   const app = await NestFactory.create(AppModule);
   
   const { httpAdapter } = app.get(HttpAdapterHost);
   app.useGlobalFilters(new AllExceptionsFilter(httpAdapter));
   
   await app.listen(3000);
   }
   bootstrap();

2. APP_FILTER 여기

• request, response 객체에 접근 가능
• next() 미들웨어 함수에 접근 가능

• Express 미들웨어와 거의 동일

  미들웨어 기능은 다음 작업을 수행할 수 있습니다.

  • 어떤 코드라도 실행하세요.
  • 요청 및 응답 개체를 변경합니다.
  • 요청-응답 주기를 종료합니다.
  • 스택에서 다음 미들웨어 함수를 호출합니다.
  • 현재 미들웨어 기능이 요청-응답 주기를 종료하지 않으면 next()다음 미들웨어 기능으로 제어를 전달하기 위해 호출해야 합니다. 그렇지 않으면 요청이 중단된 상태로 유지됩니다.

@Injectable() 데코레이터로 middleware Function Or Class 생성

• NestMiddleware 인터페이스 를 implements

  Express미들웨어를 다르게 처리 하고 fastify다양한 메소드 서명을 제공합니다. 자세한 내용은 여기를 참조하세요 .

import { Injectable, NestMiddleware } from '@nestjs/common';
import { Request, Response, NextFunction } from 'express';

@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    console.log('Request...');
    next();
  }
}

Dependency injection

DI 가능하고,constructor 를 통해 처리

Applying middleware

Module 내 configure() 함수를 통해 등록

• NestModule 인터페이스를 implements

import { Module, NestModule, MiddlewareConsumer } from '@nestjs/common';
import { LoggerMiddleware } from './common/middleware/logger.middleware';
import { CatsModule } from './cats/cats.module';

@Module({
  imports: [CatsModule],
})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer
      .apply(LoggerMiddleware)
      .forRoutes('cats');
      // 값 제한
      .forRoutes({ path: 'cats', method: RequestMethod.GET });
  }
}

async/await(예시, "configure()" 함수 내부에서 비동기 작업 처리) 를 통해 configure() 함수가 비동기 함수가 될 수 있습니다.

Express 어댑터 사용 시, body-parser 패키지에서 json 과 urlencoded 를 등록합니다. MiddlewareConsumer 로 미들웨어를 customize 할 시, NestFactory.create() 내 bodyParser 를 false 로 설정해 전역 미들웨어 처리를 하지 않아야 합니다.

Route wildcards

경로 상 Pattern 지원

forRoutes({ path: 'ab*cd', method: RequestMethod.ALL });

• 하이픈(-) 과 점(.) 은 문자열 처리

  fastify 패키지는 최신의 path-to-regexp 패키지를 쓰고 있는데, 이는 더 이상 * 를 지원하지 않습니다. 대신에, parameters 를 사용해야 합니다(예시, (.) , `:splat`).

Middleware consumer

MiddlewareConsumer 는 Helper 클래스의 일종으로, 미들웨어를 관리하기 위한 내장 함수 제공

• fluent style 로 연결됨
• 예시, forRoutes() 함수에는 단일-복수 문자열, RouteInfo 객체, 단일-복수 controller class 들어옴

  import { Module, NestModule, MiddlewareConsumer } from '@nestjs/common';
  import { LoggerMiddleware } from './common/middleware/logger.middleware';
  import { CatsModule } from './cats/cats.module';
  import { CatsController } from './cats/cats.controller';
  

@Module({ imports: [CatsModule], }) export class AppModule implements NestModule { configure(consumer: MiddlewareConsumer) { consumer .apply(LoggerMiddleware) .forRoutes(CatsController); } }

> `apply()` 함수는 단일 미들웨어와 [복수 미들웨어](https://docs.nestjs.com/middleware#multiple-middleware)를 위한 복수 변수를 인자로 받습니다.

### Excluding routes
미들웨어가 적용되는 route 를 배제하고 싶을 때, `exclude()` 함수 사용
- 단일-복수 문자열, `RouteInfo` 객체 적용
```typescript
consumer
  .apply(LoggerMiddleware)
  .exclude(
    { path: 'cats', method: RequestMethod.GET },
    { path: 'cats', method: RequestMethod.POST },
    'cats/(.*)',
  )
  .forRoutes(CatsController);

exclude() 함수는 path-to-regexp 패키지에서 지원하는 와일드카드 매개 변수를 지원합니다.

Functional middleware

단일 함수 형태로도 적용 가능

import { Request, Response, NextFunction } from 'express';

export function logger(req: Request, res: Response, next: NextFunction) {
  console.log(`Request...`);
  next();
};

consumer
  .apply(logger)
  .forRoutes(CatsController);

미들웨어에 종속성이 필요하지 않은 경우 함수형 미들웨어를 고려해보세요

Multiple middleware

순차적으로 적용되는 미들웨어는 단순 comma 로 apply() 함수에 적용 가능

consumer.apply(cors(),helmet(),logger).forRoutes(CatsController);

Global middleware

INestApplication 인스턴스에서 제공하는 use() 함수를 통해 모든 route 에 적용할 수 있음

const app = await NestFactory.create(AppModule);
app.use(logger);
await app.listen(3000);

글로벌 미드웨어에서는 DI 컨테이너에 접근할 수 없습니다. 이를 위해 app.use() 함수에 함수형 미들웨어를 적용할 수 있습니다. 혹은, 클래스 미들웨어를 AppModule(혹은 다른 모듈) 에서 .forRoutes('*') 와 함께 사용할 수 있습니다

Root 모듈(최상단) 을 통해 Nest 구조를 그림

• Module 과 Provider 의 관계와 의존성을 해결하기 위한 데이터임
• Module 을 통해 구성 요소 구현
• 연관된 기능을 묶음으로 캡슐화

Module() 내부 속성

• provider 자체적으로 캡슐화함
• 자체 모듈에 속하지 않거나, import 하지 않은 건 전달할 수 없음
• export 을 interface or API 로 간주

Feature modules

기능에 연관된 코드들끼리 모아놓는 것

• 복잡성을 줄이고, SOLID 원칙 유지

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class CatsModule {}

CLI를 사용하여 모듈을 생성하려면 $ nest g module cats명령을 실행하기만 하면 됩니다.

import { Module } from '@nestjs/common';
import { CatsModule } from './cats/cats.module';

@Module({
  imports: [CatsModule],
})
export class AppModule {}

Shared modules

Module 은 기본 singleton 이며, 공통 instance 를 공유할 수 있음

• 자동적으로 Shared modules 임

  

  ```typescript import { Module } from '@nestjs/common'; import { CatsController } from './cats.controller'; import { CatsService } from './cats.service';

@Module({ controllers: [CatsController], providers: [CatsService], exports: [CatsService] // shared modules }) export class CatsModule {}

### Module re-exporting

```typescript
@Module({
  imports: [CommonModule],
  exports: [CommonModule],
})
export class CoreModule {}

이로 인해, CoerModule 을 통해 CommonModule 의 provider 에 접근이 가능

Dependency injection

모듈 자체적으로도 provider 를 주입할 수 있음

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class CatsModule {
  constructor(private catsService: CatsService) {}
}

주로 Config 에 적용되는데, 문자 그대로 해당 Module 이 생성될 때 init 됨

• 다만, 순환 종속성으로 인해 Module 클래스 자체로 주입할 수 없음

Global modules

모듈 범위 내에서 캡슐화되기 때문에, 가져오지 않으면 사용할 수 없음 @Global() 데코레이터로 전역적으로 사용 가능

import { Module, Global } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Global()
@Module({
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService],
})
export class CatsModule {}

• root or core 모듈에 한 번만 등록되어야 함

  모든 것을 글로벌하게 만드는 것은 좋은 디자인 결정이 아닙니다. 불필요한 상용구의 양을 줄이기 위해 전역 모듈을 사용할 수 있습니다. Imports은 일반적으로 소비자가 모듈의 API를 사용할 수 있도록 하는 데 선호되는 방법입니다.

Dynamic modules

provider 를 동적으로 등록할 수 있게 해주는 custom module

• 여기