NestJS Fundamentals - Custom Provider

Min Su Kwon·2021년 12월 6일
nest
1

Nest JS 공식문서 번역하기

목록 보기
11/11
post-thumbnail
post-custom-banner

앞선 챕터들에서 의존성 주입의 다양한 측면과 Nest에서 어떻게 사용되는지에 대해서 살펴봤다. 하나의 예시는 생성자 기반의 의존성 주입으로, 특정 인스턴스를 클래스에게 주입하고 싶을 때 사용할 수 있었다. 애플리케이션의 규모가 커지고 복잡해질수록 의존성 주입 시스템의 다른 기능들을 활용해야할때가 오게되니, 조금 더 자세히 살펴보자.

DI fundamentals

의존성 주입은 제어 역전 기법(IoC)으로, IoC 컨테이너의 의존성 인스턴스화 책임을 시스템(Nest의 경우에는 Nest의 런타임 시스템)에게 위임하는 것이다.

먼저, 프로바이더를 정의해야한다. @Injectable() 데코레이터를 사용해서 CatsService클래스를 프로바이더로 만들 수 있다.

import { Injectable } from '@nestjs/common';
import { Cat } from './interfaces/cat.interface';

@Injectable()
export class CatsService {
  private readonly cats: Cat[] = [];

  findAll(): Cat[] {
    return this.cats;
  }
}

다음으로, Nest에게 방금 만든 프로바이더를 컨트롤러 클래스에 주입해주도록 요청한다.

import { Controller, Get } from '@nestjs/common';
import { CatsService } from './cats.service';
import { Cat } from './interfaces/cat.interface';

@Controller('cats')
export class CatsController {
  constructor(private catsService: CatsService) {}

  @Get()
  async findAll(): Promise<Cat[]> {
    return this.catsService.findAll();
  }
}

마지막으로, 프로바이더를 Nest IoC 컨테이너에 등록해준다.

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

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

실제로는 다음과 같은 과정이 지나간다.

  1. cats.service.ts에서, @Injectable() 데코레이터가 CatsService 클래스가 Nest IoC 컨테이너에 의해 관리될 수 있다는 것을 선언해준다.
  2. cats.controller.ts에서, CatsController가 생성자 주입을 통해 CatsService 토큰에 대한 의존성을 선언한다.
constructor(private catsService: CatsService)
  1. app.module.ts에서, CatsService 토큰과 cats.service.ts 파일에서 온 CatsService 클래스를 연결짓는다. 연결과정은 아래에서 자세히 다룬다.

Nest IoC 컨테이너가 CatsController를 인스턴스화 할 때, 다른 의존성이 있는지부터 확인한다. CatsService 의존성을 발견한 뒤에는, CatsService 토큰에 대해서 찾아보게 되며, 이 결과로 CatsService 클래스를 받게 된다. Nest는 이를 SINGLETON 스코프로 간주하며, 새로운 CatsService 인스턴스를 만들거나, 캐싱하고 반환하거나, 이미 캐시에 존재하는 인스턴스를 반환한다.

위의 설명은 많이 단순화된 것으로, 의존성을 정리하는 과정이 굉장히 복잡하며 애플리케이션 부트스트랩 과정에서 발생한다는 점을 기억해야한다. 한가지 주요 기능은 종속성 분석(또는 종속성 그래프 생성) 과정이 전이적이라는 것으로, 위의 예시에서 CatsService 자체에 종속성이 있었다면 이또한 주입되었을 것이다. 종속성 그래프를 통해서 의존성이 올바른 순서로 주입된다는 확신을 얻을 수 있다. 이 매커니즘 덕분에 개발자가 복잡한 의존성 그래프를 관리할 필요가 없어진다.

Standard providers

@Module() 데코레이터를 자세히 살펴보자. app.module에서, 아래와 같이 선언한다.

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

providers 프로퍼티는 프로바이더들의 배열을 받는다. 현재까지는 클래스 이름들을 여기에 넣어줬지만, providers: [CatsService]라는 구문은 사실 아래와 같이 좀 더 복잡한 문법의 short-hand다.

providers: [
	{
		provide: CatsService,
		useClass: CatsService,
	}
]

위의 명시적인 구조를 봤으니, 이제 등록 프로세스에 대해서 이해할 수 있다. 여기서, 명백히 CatsService라는 토큰을 CatsService 클래스와 연결짓고 있다. 이 단순 표기법은 편의성을 제공하기 위한 표기법으로, 같은 이름을 가진 클래스 인스턴스를 요청하기 위한 토큰을 사용하는 가장 간단한 유즈케이스를 단순화해준다.

Custom providers

위의 표준 프로바이더 방법이 아닌 다른 방법으로 사용해야 한다면, 예를 들어

  • 직접 커스텀 인스턴스를 만들고 싶은 경우
  • 두번째 의존성에 존재하는 클래스를 재사용하고 싶을 경우
  • 테스트를 위해 클래스를 오버라이드 하고싶은 경우

Nest는 이런 케이스들을 핸들링하기 위해 커스텀 프로바이더를 정의할 수 있도록 해준다.

Value providers: useValue

useValue 문법은 상수 값을 주입해야하거나, 외부 라이브러리를 네스트 컨테이너에 주입해야하거나, 실제 구현을 mock 객체로 대체해야할 때 유용하다. 네스트가 테스트를 위해 mock CatsService를 사용하도록 강제해보자.

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

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

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

위의 예에서, CatsService 토큰은 mockCatsService mock 객체로 resolve 된다. useValue는 값을 받아서 타입스크립트의 구조적 타이핑 덕분에 동일한 구조를 가진 값이라면 얼마든지 사용할 수 있다.

Non-class-based provider tokens

현재까지는, 클래스이름을 직접 프로바이더 토큰으로 사용해왔다. 이는 생성자 기반의 의존성 주입을 할때 표준 패턴과 일치하며, 여기서도 토큰이 곧 클래스 이름이다. 가끔 문자열이나 심벌을 의존성 주입 토큰으로 사용하고 싶을 수 있다. 예를 들면

import { connection } from './connection';

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

위의 예시에서, 'CONNECTION'이라는 문자열 토큰과 connection 객체를 연결지었다.

문자열은 물론이고, 자바스크립트 심벌이나 타입스크립트 enum도 토큰 값으로 사용할 수 있다

생성자 기반의 표준 의존성 주입을 할 때는, 의존성이 클래스이름으로 선언되었어야 했다. 하지만 'CONNECTION' 커스텀 프로바이더는 문자열 토큰을 사용한다. 이런 경우는 아래와 같이 @Inject() 데코레이터를 사용해서 의존성 주입을 할 수 있다. 이 데코레이터는 토큰 하나를 인자로 받는다.

@Injectable()
export class CatsRepository {
  constructor(@Inject('CONNECTION') connection: Connection) {}
}

위 예시에서는 'CONNECTION' 토큰을 직접 사용했지만, 깔끔한 코드 정리를 위해서는 토큰을 별도의 파일로 분리해서 심벌 또는 enum으로 사용하는 것이 권장된다.

Class providers : useClass

useClass 문법은 동적으로 어떤 토큰이 어떤 클래스로 resolve 되어야 하는지 판단할 수 있도록 도와준다. 예를 들어, ConfigService 클래스가 있고, 환경에 따라서 네스트가 다른 config 서비스를 주입하길 원한다고 해보자. 아래철머 useClass를 사용하면된다.

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

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

위 예시에서는 configServiceProvider를 리터럴 객체로 먼저 선언해놓고, 모듈 데코레이터의 providers 프로퍼티에게 넘겨준다. 이는 깔끔한 코드를 위한 선택으로, 이전에 봤던 것과 다른 점은 없다고 보면된다.

또한, ConfigService 클래스 이름을 토큰으로 사용했다. ConfigService에 의존하는 모든 클래스에 대해서 네스트는 DevelopmentConfigService 또는 ProductionConfigService 클래스를 주입하게 된다.

Factory providers : useFactory

useFactory 문법은 동적으로 프로바이더를 만들 수 있도록 해준다. 실제 프로바이더는 팩토리 함수에서 반환하는 값이 된다. 여기서 팩토리 함수는 원하는만큼 간단할수도, 복잡할 수도 있다. 간단한 팩토리는 다른 프로바이더에 의존해서는 안되지만, 복잡한 팩토리는 다른 프로바이더를 사용할 수도 있다. 후자의 경우에, 팩토리 프로바이더 문법이 두가지 관련 메커니즘을 가지게 된다.

  1. 팩토리 함수는 옵셔널한 매개변수(들)을 받을 수 있다.
  2. 옵셔널한 inject 프로퍼티는 필요한 프로바이더들을 배열로 받는다. 의존성 주입은 네스트가 해준다. inject에 있는 프로바이더들의 순서와 팩토리 함수에 있는 매개변수의 순서는 일치해야한다.
const connectionFactory = {
  provide: 'CONNECTION',
  useFactory: (optionsProvider: OptionsProvider) => {
    const options = optionsProvider.get();
    return new DatabaseConnection(options);
  },
  inject: [OptionsProvider],
};

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

Factory providers : useExisting

useExisting 문법은 이미 존재하는 프로바이더에게 별명을 붙일 수 있도록 해준다. 이는 같은 프로바이더에 접근하기 위한 두가지 방법을 제공하는 셈이 된다. 아래의 예시에서, 'AliasedLoggerService' 토큰은 LoggerService의 별명이 된다. 만약 두 의존성이 모두 SINGLETON 스코프로 설정되었다면, 둘은 같은 인스턴스로 resolve된다.

@Injectable()
class LoggerService {
  /* implementation details */
}

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

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

Non-service based providers

프로바이더들은 주로 서비스들을 제공하지만, 항상 그래야만 하는 것은 아니다. 프로바이더는 아무 값이나 제공할 수 있다. 예를 들어, 현재 환경에 맞는 config 객체를 제공할 수 있다.

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

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

Export custom provider

다른 프로바이더들 처럼, 커스텀 프로바이더는 선언 모듈 쪽에 맞게 스코핑된다. 다른 모듈들이 이를 볼 수 있게 하려면, export 되어야 한다. 커스텀 프로바이더를 export 하려면, 토큰을 사용하거나 전체 프로바이더 객체를 사용하면 된다.

const connectionFactory = {
  provide: 'CONNECTION',
  useFactory: (optionsProvider: OptionsProvider) => {
    const options = optionsProvider.get();
    return new DatabaseConnection(options);
  },
  inject: [OptionsProvider],
};

@Module({
  providers: [connectionFactory],
  exports: ['CONNECTION'],
})
export class AppModule {}
const connectionFactory = {
  provide: 'CONNECTION',
  useFactory: (optionsProvider: OptionsProvider) => {
    const options = optionsProvider.get();
    return new DatabaseConnection(options);
  },
  inject: [OptionsProvider],
};

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

느낀 점

이제야 좀 nest js에서 의존성 주입이 정확히 어떻게 이뤄지는 것인지, 또 표준으로 제공하는 방법외에 어떻게 응용해서 사용할 수 있는지 이해하게 된 것 같다. 결국 유니크한 토큰으로 각각 프로바이더를 구분하는거고, 요거를 런타임에 nest js가 알맞은 녀석을 찾아서 넣어준다. 이렇게 이해하면 될 것 같다. 위에서 다룬 내용들 중 useFatory를 이용해서 동적인 프로바이더를 만드는 작업을 해보고싶다.

profile
Min Su Kwon
이제 막 커리어를 시작한 소프트웨어 엔지니어입니다. 배운 것을 정리하면서 조금 더 깊이 이해하려는 습관을 들이려고 합니다. 피드백은 언제나 환영입니다.
이전 포스트

NestJS Overview - Custom Decorators

post-custom-banner

0개의 댓글