For people coming from different programming language backgrounds, it might be unexpected to learn that in Nest, almost everything is shared across incoming requests. We have a connection pool to the database, singleton services with global state, etc. Remember that Node.js doesn't follow the request/response Multi-Threaded Stateless Model in which every request is processed by a separate thread. Hence, using singleton instances is fully safe for our applications.
However, there are edge-cases when request-based lifetime may be the desired behavior, for instance per-request caching in GraphQL applications, request tracking, and multi-tenancy. Injection scopes provide a mechanism to obtain the desired provider lifetime behavior.
A provider can have any of the following scopes:
|A single instance of the provider is shared across the entire application. The instance lifetime is tied directly to the application lifecycle. Once the application has bootstrapped, all singleton providers have been instantiated. Singleton scope is used by default.|
|A new instance of the provider is created exclusively for each incoming request. The instance is garbage-collected after the request has completed processing.|
|Transient providers are not shared across consumers. Each consumer that injects a transient provider will receive a new, dedicated instance.|
info Hint Using singleton scope is recommended for most use cases. Sharing providers across consumers and across requests means that an instance can be cached and its initialization occurs only once, during application startup.
Specify injection scope by passing the
scope property to the
@Injectable() decorator options object:
Similarly, for custom providers, set the
scope property in the long-hand form for a provider registration:
info Hint Import the
warning Notice Gateways should not use request-scoped providers because they must act as singletons. Each gateway encapsulates a real socket and cannot be instantiated multiple times.
Singleton scope is used by default, and need not be declared. If you do want to declare a provider as singleton scoped, use the
Scope.DEFAULT value for the
Controllers can also have scope, which applies to all request method handlers declared in that controller. Like provider scope, the scope of a controller declares its lifetime. For a request-scoped controller, a new instance is created for each inbound request, and garbage-collected when the request has completed processing.
Declare controller scope with the
scope property of the
Scope bubbles up the injection chain. A controller that depends on a request-scoped provider will, itself, be request-scoped.
Imagine the following dependency graph:
CatsController <- CatsService <- CatsRepository. If
CatsService is request-scoped (and the others are default singletons), the
CatsController will become request-scoped as it is dependent on the injected service. The
CatsRepository, which is not dependent, would remain singleton-scoped.
In an HTTP server-based application (e.g., using
@nestjs/platform-fastify), you may want to access a reference to the original request object when using request-scoped providers. You can do this by injecting the
Because of underlying platform/protocol differences, you access the inbound request slightly differently for Microservice or GraphQL applications. In GraphQL applications, you inject
CONTEXT instead of
You then configure your
context value (in the
GraphQLModule) to contain
request as its property.
Using request-scoped providers will have an impact on application performance. While Nest tries to cache as much metadata as possible, it will still have to create an instance of your class on each request. Hence, it will slow down your average response time and overall benchmarking result. Unless a provider must be request-scoped, it is strongly recommended that you use the default singleton scope.