Injection scopes
nest의 공식문서를 토대로 작성합니다.
Node.js는 모든 요청이 별도의 스레드에서 처리되는 요청/응답 다중 스레드 stateless 모델을 따르지 않습니다. 따라서 싱글톤 인스턴스를 사용하는 것은 안전합니다.
그러나 GraphQL 애플리케이션의 요청별 캐싱, 요청 추적, 멀티테넌시 등 요청 기반 수명이 바람직한 동작일 수 있는 케이스가 있습니다. Injection scpoes는 원하는 provider 수명 동작을 얻을 수 있는 메커니즘을 제공합니다.
싱글톤이 뭔지 까먹어서 다시 찾아봤습니다ㅋㅋ: )
싱글톤 패턴?
하나의 클래스에 오직 하나의 객체 인스턴스만 가지는 패턴.
하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 어디에서든 공유하며 접근, 사용 가능한 것.
https://velog.io/@cxzaqq/NESTJS%EB%A5%BC-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%905#shared-modules
Provider scope
provider는 다음 범위 중 하나를 가질 수 있습니다:
-
DEFAULT
provider의 단일 인스턴스가 전체 애플리케이션에서 공유. 인스턴스 수명은 애플리케이션 수명 주기에 묶임. 애플리케이션이 부트스트랩되면 모든 싱글톤 provider가 인스턴스화됨. 기본적으로 싱글톤 범위가 사용. -
REQUEST
들어오는 각 요청에 대해 provider의 새 인스턴스가 독점적으로 생성. 인스턴스는 요청 처리가 완료된 후 garbage-collected(메모리 공간 확보). -
TRANSIENT
임시 provider는 소비자 간에 공유되지 않음. 임시 provider를 주입하는 각 소비자는 새로운 전용 인스턴스를 받음.
HINT
대부분의 사용 사례에서는 싱글톤 범위를 사용하는 것을 권장. 소비자 및 요청 간에 provider를 공유하면 인스턴스를 캐시할 수 있고 애플리케이션 시작 중에 한 번만 초기화가 수행.
Usage
범위 속성을 @Injectable() 데코레이터 옵션 객체에 전달하여 주입 범위를 지정합니다:
import { Injectable, Scope } from '@nestjs/common';
@Injectable({ scope: Scope.REQUEST })
export class CatsService {}사용자 지정 provider의 경우 마찬가지로 범위 속성 설정:
{
provide: 'CACHE_MANAGER',
useClass: CacheManager,
scope: Scope.TRANSIENT,
}싱글톤 범위가 기본적으로 사용되며 선언할 필요 없습니다. provider를 싱글톤 범위로 선언하려면 범위 속성에 Scope.DEFAULT 값을 사용합니다.
NOTICE
웹소켓 게이트웨이는 싱글톤으로 작동해야하므로 요청 범위가 지정된 provider를 사용하면 안 됨. 각 게이트웨이는 실제 소켓을 캡슐화하며 여러번 인스턴스화할 수 없음. 이 제한은 Passport 전략이나 크론 컨트롤러와 같은 다른 일부 provider에게도 적용.
Controller scope
컨트롤러는 해당 컨트롤러에 선언된 모든 요청 메소드 핸들러에 적용되는 범위를 가질 수도 있습니다. provider 범위와 마찬가지로 컨트롤러 범위는 수명을 선언합니다. 요청 범위 컨트롤러의 경우 각 인바운드 요청에 대해 새 인스턴스가 생성되고 요청 처리가 완료되면 garbage-collected 됩니다.
ControllerOptions 객체의 scope 속성을 사용하여 컨트롤러 범위를 선언합니다:
@Controller({
path: 'cats',
scope: Scope.REQUEST,
})
export class CatsController {}Scope hierarchy
REQUEST 범위는 injection chain에 버블을 형성합니다. 요청 범위가 지정된 provider에 의존하는 컨트롤러는 그 자체로 요청 범위가 지정됩니다. 즉 따로 설정을 하지 않아도 provider의 범위를 따라갑니다.
다음 의존성 그래프를 생각해봅시다: CatsController <- CatsService <- CatsRepository. CatsService가 요청 범위에 지정되어 있고 나머지는 기본 싱글톤인 경우, 주입된 서비스에 종속되어 있기 때문에 CatsController는 요청 범위로 지정됩니다. 종속되지 않은 CatsRepository는 싱글톤 범위로 유지됩니다.
일시적 범위의 종속성은 이 패턴을 따르지 않습니다. 싱글톤 범위의 DogsService가 일시적인 LoggerService provider를 주입하면 새로운 인스턴스를 받게 됩니다. 그러나 DogsService는 싱글톤 범위로 유지되므로 아무곳에나 주입해도 DogsService의 새 인스턴스로 해결되지 않습니다. 이러한 동작을 원한다면 DogsService도 명시적으로 TRANSIENT로 표시해야 합니다.
Request provider
HTTP 서버 기반 애플리케이션(예: @nestjs/platform-express 또는 @nestjs/platform-fastify 사용)에서는 요청 범위가 지정된 provider를 사용할 때 원본 요청 객체에 대한 참조에 접근하고 싶을 수 있습니다. REQUEST 객체를 주입하면 이 작업을 수행할 수 있습니다.
import { Injectable, Scope, Inject } from '@nestjs/common';
import { REQUEST } from '@nestjs/core';
import { Request } from 'express';
@Injectable({ scope: Scope.REQUEST })
export class CatsService {
constructor(@Inject(REQUEST) private request: Request) {}
}기본 platform/protocol 차이로 인해 마이크로서비스 또는 GraphQL 애플리케이션의 경우 인바운드 요청에 약간 다르게 접근합니다. GraphQL 애플리케이션에서는 REQUEST 대신 CONTEXT를 주입합니다:
import { Injectable, Scope, Inject } from '@nestjs/common';
import { CONTEXT } from '@nestjs/graphql';
@Injectable({ scope: Scope.REQUEST })
export class CatsService {
constructor(@Inject(CONTEXT) private context) {}
}그 후 request를 속성으로 포함하도록 context 값을 구성합니다(GraphQLModule에서).
Inquirer porvider
예를 들어 로깅 또는 metrics provider에서 provider가 생성된 클래스를 가져오려면 INQUIRER 토큰을 삽입하면 됩니다.
import { Inject, Injectable, Scope } from '@nestjs/common';
import { INQUIRER } from '@nestjs/core';
@Injectable({ scope: Scope.TRANSIENT })
export class HelloService {
constructor(@Inject(INQUIRER) private parentClass: object) {}
sayHello(message: string) {
console.log(`${this.parentClass?.constructor?.name}: ${message}`);
}
}그 후 다음과 같이 사용합니다:
import { Injectable } from '@nestjs/common';
import { HelloService } from './hello.service';
@Injectable()
export class AppService {
constructor(private helloService: HelloService) {}
getRoot(): string {
this.helloService.sayHello('My name is getRoot');
return 'Hello world!';
}
}위의 예제에서 AppService#getRoot가 호출되면 "AppService: My name is getRoot"가 콘솔에 출력됩니다.
Performance
요청 범위가 지정된 provider를 사용하면 애플리케이션 성능에 영향을 미칩니다. Nest는 가능한 많은 메타데이터를 캐시하려고 시도하지만 각 요청에 대해 클래스의 인스턴스를 생성해야 합니다. 따라서 평균 응답 시간과 전반적인 벤치마킹 결과가 느려집니다. provider가 요청 범위를 지정해야 하는 경우가 아니라면 기본 싱글톤 범위를 사용할 것을 강력히 권장합니다.
HINT
이 모든것이 상당히 위협적으로 들리지만 요청 범위가 지정된 provider를 활용하는 적절하게 설계된 애플리케이션은 지연 시간이 최대 5% 이상 느려지지 않아야 함.
Durable providers
위에서 언급했듯이 요청 범위가 지정된 provider를 하나 이상 사용하면 컨트롤러도 요청 범위가 지정되므로 지연 시간이 늘어날 수 있습니다. 즉, 각 개별 요청마다 컨트롤러를 다시 생성(인스턴스화)해야 하고 나중에 garbage-collected 해야 합니다. 이것은 3만 개의 요청이 병렬로 발생한다고 가정하면 컨트롤러(및 요청 범위가 지정된 provider)의 임시 인스턴스가 3만개가 된다는 뜻이기도 합니다.
대부분의 provider가 의존하는 공통 provider(데이터베이스 연결 또는 로거 서비스 등)가 있으면 모든 provider가 요청 범위 공급자로 자동 변환됩니다. 이는 multi-tenant 애플리케이션, 특히 request 객체에서 헤더/토큰을 가져와 그 값을 기반으로 해당 데이터베이스 연결/스키마를 검색하는 중앙 요청 범위의 "데이터 소스" provider가 있는 애플리케이션의 경우 문제가 될 수 있습니다.
예를 들어 10명의 고객이 번갈아 사용하는 애플리케이션이 있다고 가정합니다. 각 고객마다 고유한 전용 데이터 소스가 있으며 고객 A가 고객 B의 데이터베이스에 접근할 수 없도록 하고 싶을 것입니다. 이를 달성하는 한 가지 방법은 요청 객체를 기반으로 '현재 고객'을 판단하고 해당 데이터베이스를 검색하는 요청 범위가 지정된 '데이터 소스' provider를 선언하는 것입니다. 이 접근 방식을 사용하면 단 몇 분만에 애플리케이션을 multi-tenant 애플리케이션으로 전환할 수 있습니다. 하지만 이 접근 방식의 가장 큰 단점은 애플리케이션 구성 요소의 상당 부분이 '데이터 소스' provider에 의존할 가능성이 높기 때문에 암시적으로 요청 범위가 지정되므로 앱 성능에 영향을 미칠 수 있다는 것입니다.
하지만 더 나은 해결책이 있다면 어떨까요? 고객이 10명뿐이므로 요청마다 각 트리를 다시 만드는 대신 고객당 10개의 개별 DI 하위 트리를 가질 수는 없을까요? provider가 각 연속 요청에 대해 진정으로 고유한 속성(예: request UUID)에 의존하지 않고 대신 요청을 분류할 수 있는 몇 가지 특정 속성이 있다면 들어오는 모든 요청에 대해 DI 하위 트리를 다시 만들 이유가 없습니다.
바로 이때 durable providers가 유용합니다.
provider를 durable로 flagging하기 전에 먼저 Nest에 '공통 요청 속성'이 무엇인지 알려주는 전략을 등록하고 요청을 그룹화하는 로직을 제공하여 해당 DI 하위 트리와 연결해야 합니다.
import {
HostComponentInfo,
ContextId,
ContextIdFactory,
ContextIdStrategy,
} from '@nestjs/core';
import { Request } from 'express';
const tenants = new Map<string, ContextId>();
export class AggregateByTenantContextIdStrategy implements ContextIdStrategy {
attach(contextId: ContextId, request: Request) {
const tenantId = request.headers['x-tenant-id'] as string;
let tenantSubTreeId: ContextId;
if (tenants.has(tenantId)) {
tenantSubTreeId = tenants.get(tenantId);
} else {
tenantSubTreeId = ContextIdFactory.create();
tenants.set(tenantId, tenantSubTreeId);
}
// If tree is not durable, return the original "contextId" object
return (info: HostComponentInfo) =>
info.isTreeDurable ? tenantSubTreeId : contextId;
}
}HINT
요청 범위와 마찬가지로 durable은 주입 체인에 거품을 일으킴. 즉 A가 durable로 플래그가 지정된 B에 종속된 경우 A provider에 대해 durable이 명시적으로 false로 설정되어 있지 않는 한 암시적으로 A도 durable이 됨.
WARNING
이 전략은 많은 수의 tenant로 운영되는 애플리케이션에는 적합하지 않음.
attach 메소드에서 반환된 값은 주어진 호스트에 대해 어떤 컨텍스트 식별자를 사용해야 하는지 Nest에 지시합니다. 이 예제에서는 호스트 컴포넌트(예: 요청 범위 컨트롤러)가 durable로 플래그가 지정된 경우 원래의 자동 생성된 contextId 객체 대신 tenantSubTreeId를 사용하도록 지정했습니다. 또한 위의 예시에서는 payload가 등록되지 않습니다.(여기서 payload는 하위 트리의 부모인 '루트'를 나타내는 REQUEST/CONTEXT provider)
// The return of `AggregateByTenantContextIdStrategy#attach` method:
return {
resolve: (info: HostComponentInfo) =>
info.isTreeDurable ? tenantSubTreeId : contextId,
payload: { tenantId },
}이제 @Inject(REQUEST)/@Inject(CONTEXT)를 사용하여 요청 provider(또는 GraphQL 애플리케이션의 경우 CONTEXT)를 주입할 때마다 payload 객체가 주입됩니다(단일 속성으로 구성됨).
이 전략이 마련되면 코드 어딘가에 등록할 수 있으므로(어쨌든 global하게 적용) 예를 들어 main.ts에 파일에 배치할 수 있습니다:
ContextIdFactory.apply(new AggregateByTenantContextIdStrategy());요청이 애플리케이션에 도달하기 전에 등록이 이루어지면 모든 것이 의도한 대로 작동합니다.
마지막으로 일반 provider를 durable provider로 전환하려면 durable 플래그를 true로 설정하고 해당 범위를 Scope.REQUEST로 변경하면 됩니다(REQUEST 범위가 이미 인젝션 체인에 있는 경우 필요 없음):
import { Injectable, Scope } from '@nestjs/common';
@Injectable({ scope: Scope.REQUEST, durable: true })
export class CatsService {}마찬가지로 사용자 지정 provider의 경우 provider 등록을 위한 long-hand 양식에서 durable 속성을 설정합니다:
{
provide: 'foobar',
useFactory: () => { ... },
scope: Scope.REQUEST,
durable: true,
}고생하셨습니다!
다음 글에서 만나요~~😀
저도 아직 배우는 단계입니다. 지적 감사히 받겠습니다. 함께 열심히 공부해요!!
