Custom providers
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 {}실제로는 다음과 같은 과정으로 진행됩니다.
cats.service.ts에서,@Injectable()데코레이터가CatsService클래스가 Nest IoC 컨테이너에 의해 관리될 수 있다는 것을 선언.cats.controller.ts에서,CatsController가 생성자 주입을 통해CatsService토큰에 대한 의존성을 선언.app.module.ts에서,CatsService토큰과cats.service.ts파일에서 온CatsService클래스를 연결.
연결과정은 아래에서 자세히 다룹니다.
Nest IoC 컨테이너가 CatsController를 인스턴스화 할 때, 다른 의존성이 있는지부터 확인합니다. CatsService 의존성을 발견한 뒤에는, CatsService 토큰에 대해서 찾아보게 되며, 이 결과로 CatsService 클래스를 받게 됩니다. Nest는 이를 SINGLETON 스코프로 간주하며, 새로운 CatsService 인스턴스를 만들거나, 캐싱하고 반환하거나, 이미 캐시에 존재하는 인스턴스를 반환합니다.
위의 설명은 많이 단순화된 것으로, 의존성을 정리하는 과정이 굉장히 복잡하며 애플리케이션 부트스트랩 과정에서 발생한다는 점을 기억해야합니다.
Standard providers
@Module({
controllers: [CatsController],
providers: [CatsService],
})이 코드의 providers는 사실 아래와 같이 작동합니다.
providers: [
{
provide: CatsService,
useClass: CatsService,
},
];위의 명시적인 구조를 봤으니, 이제 등록 프로세스에 대해서 이해할 수 있게 되었습니다!
여기서, 명백히 CatsService라는 토큰을 CatsService 클래스와 연결짓고 있습니다.
이 단순 표기법은 편의성을 제공하기 위한 표기법으로, 같은 이름을 가진 클래스 인스턴스를 요청하기 위한 토큰을 사용하는 가장 간단한 유즈케이스를 단순화해주는 것 입니다.
Custom providers
위의 표준 프로바이더 방법이 아닌 다른 방법으로 사용하고 싶은 분들을 위해 Nest는 커스텀 프로바이더를 정의할 수 있도록 해줍니다.
ex )
직접 커스텀 인스턴스를 만들고 싶은 경우
두번째 의존성에 존재하는 클래스를 재사용하고 싶을 경우
테스트를 위해 클래스를 오버라이드 하고싶은 경우
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 {}Non-class-based provider tokens
현재까지는, 클래스이름을 직접 프로바이더 토큰으로 사용해왔습니다.
이는 생성자 기반의 의존성 주입을 할때 표준 패턴과 일치하며, 여기서도 토큰이 곧 클래스 이름입니다.
가끔은 문자열이나 심벌을 의존성 주입 토큰으로 사용하고 싶을 수 있습니다.
import { connection } from './connection';
@Module({
providers: [
{
provide: 'CONNECTION',
useValue: connection,
},
],
})
export class AppModule {}위의 예시에서, '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 프로퍼티에게 넘겨준다. 이는 깔끔한 코드를 위한 선택으로, 이전에 봤던 것과 다른 점은 없다고 보면된다.
Factory providers : useFactory
useFactory 문법은 동적으로 프로바이더를 만들 수 있도록 해줍니다.
실제 프로바이더는 팩토리 함수에서 반환하는 값이 됩니다.
여기서 팩토리 함수는 원하는만큼 간단할수도, 복잡할 수도 있습니다. 간단한 팩토리는 다른 프로바이더에 의존해서는 안되지만, 복잡한 팩토리는 다른 프로바이더를 사용할 수도 있습니다.
후자의 경우에, 팩토리 프로바이더 문법이 두가지 관련 메커니즘을 가지게 됩니다.
- 팩토리 함수는 옵셔널한 매개변수(들)을 받을 수 있다.
- 옵셔널한 inject 프로퍼티는 필요한 프로바이더들을 배열로 받는다. 의존성 주입은 네스트가 해준다. inject에 있는 프로바이더들의 순서와 팩토리 함수에 있는 매개변수의 순서는 일치해야한다.
const connectionProvider = {
provide: 'CONNECTION',
useFactory: (optionsProvider: OptionsProvider, optionalProvider?: string) => {
const options = optionsProvider.get();
return new DatabaseConnection(options);
},
inject: [OptionsProvider, { token: 'SomeOptionalProvider', optional: true }],
// \_____________/ \__________________/
// This provider The provider with this
// is mandatory. token can resolve to `undefined`.
};
@Module({
providers: [
connectionProvider,
OptionsProvider,
// { provide: 'SomeOptionalProvider', useValue: 'anything' },
],
})
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], //2개가 같음
})
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 하려면, 토큰을 사용하거나 전체 프로바이더 객체를 사용하면 됩니다.
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 {}
-------------------------------------------------------------------
// 전체 공급자 개체를 사용하여 내보내는 방법
@Module({
providers: [connectionFactory],
exports: [connectionFactory],
})
export class AppModule {}