Provider scope (default, request, transient) in NestJS - Step-by-Step Execution

Concept Flow - Provider scope (default, request, transient)

Start Application

↓

Resolve Provider

↓

Default Scope: Single Instance

↓

Reuse Same Instance

↓

Request Scope: New Instance Per Request

↓

Create Instance For Each Request

↓

Transient Scope: New Instance Every Injection

↓

Create New Instance Every Time

When NestJS starts, it creates providers based on their scope: default creates one shared instance, request creates a new instance per HTTP request, and transient creates a new instance every time it is injected.

Execution Sample

NestJS

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

@Injectable({ scope: Scope.REQUEST })
export class MyService {
  id = Math.random();
}

Defines a service with request scope that gets a new instance with a unique id for each HTTP request.

Execution Table

Step	Scope Type	Action	Instance Created?	Instance ID	Notes
1	Default	App starts, provider resolved first time	Yes	0.1234	Single instance created and reused
2	Default	Second injection in same app lifetime	No	0.1234	Same instance reused
3	Request	First HTTP request starts	Yes	0.5678	New instance created for request
4	Request	Second injection in same request	No	0.5678	Same instance reused within request
5	Request	Second HTTP request starts	Yes	0.9101	New instance created for new request
6	Transient	First injection anywhere	Yes	0.1111	New instance created every injection
7	Transient	Second injection anywhere	Yes	0.2222	Another new instance created
8	Transient	Third injection anywhere	Yes	0.3333	Another new instance created
9	-	App stops or no more injections	No	-	Execution ends

💡 No more injections or app stops, so no new instances created

Variable Tracker

Instance ID	Start	After Step 1	After Step 3	After Step 5	After Step 6	After Step 7	After Step 8	Final
Default Scope Instance	None	0.1234	0.1234	0.1234	0.1234	0.1234	0.1234	0.1234
Request Scope Instance	None	None	0.5678	0.9101	0.9101	0.9101	0.9101	0.9101
Transient Scope Instance	None	None	None	None	0.1111	0.2222	0.3333	0.3333

Key Moments - 3 Insights

Why does the default scope provider reuse the same instance every time?

Because in the execution_table at steps 1 and 2, the instance ID stays the same (0.1234), showing the single instance is reused throughout the app lifetime.

How does the request scope provider behave across multiple HTTP requests?

As seen in steps 3 and 5, a new instance is created for each HTTP request (IDs 0.5678 and 0.9101), but within the same request (step 4), the instance is reused.

Why does the transient scope create a new instance every time?

Because at steps 6, 7, and 8, each injection creates a new instance with a different ID, showing no reuse happens.

Visual Quiz - 3 Questions

Look at the execution_table at step 4. What is true about the request scope instance?

A It is the same instance as step 3

B It is a new instance different from step 3

C It is the same as the default scope instance

D No instance exists at this step

💡 Hint

Check the Instance ID column for steps 3 and 4 in execution_table

At which step does the transient scope create its second new instance?

A Step 6

B Step 8

C Step 7

D Step 5

💡 Hint

Look at the Instance Created? and Instance ID columns for transient scope in execution_table

If the default scope provider was changed to transient, what would happen at step 2?

A No new instance would be created

B A new instance would be created

C The app would crash

D The instance ID would stay the same

💡 Hint

Compare how transient scope creates new instances every injection in execution_table steps 6-8

Concept Snapshot

Provider scopes in NestJS control instance creation:
- Default: one shared instance for app lifetime
- Request: new instance per HTTP request
- Transient: new instance every injection
Use @Injectable({ scope: Scope.X }) to set scope.
Scopes affect memory and behavior of services.

Full Transcript

In NestJS, providers can have different scopes that control how many instances are created and when. The default scope creates one instance that is reused everywhere. The request scope creates a new instance for each HTTP request, but reuses it within that request. The transient scope creates a new instance every time the provider is injected. This example shows how instances get created and reused or recreated depending on the scope. Understanding this helps manage resource use and service behavior in your app.

Practice

1. In NestJS, what does the default provider scope mean for a service instance?

easy

A. A new instance is created for each HTTP request.

B. A single instance is shared across the entire application.

C. A new instance is created every time the service is injected.

D. The service instance is destroyed after each method call.

Solution

1. Step 1: Understand default provider scope behavior

   By default, NestJS creates one instance of a provider and shares it across the whole app.

2. Step 2: Compare with other scopes

   Request scope creates per HTTP request instances, transient creates per injection instances, so default is the shared singleton.

3. Final Answer:

   A single instance is shared across the entire application. -> Option B

4. Quick Check:

   Default scope = singleton instance [OK]

Hint: Default scope means one shared instance app-wide [OK]

Common Mistakes:

• Confusing default with request scope
• Thinking default creates new instances per injection
• Assuming default destroys instance after use

2. Which of the following is the correct way to set a provider's scope to transient in NestJS?

easy

A. @Injectable({ scope: Scope.REQUEST })

B. @Injectable({ scope: 'transient' })

C. @Injectable({ scope: Scope.TRANSIENT })

D. @Injectable({ transient: true })

Solution

1. Step 1: Recall correct syntax for setting scope

   In NestJS, the scope is set using the Scope enum inside @Injectable decorator like { scope: Scope.TRANSIENT }.

2. Step 2: Eliminate incorrect options

   @Injectable({ scope: Scope.REQUEST }) uses REQUEST scope, @Injectable({ scope: 'transient' }) uses string instead of enum, @Injectable({ transient: true }) uses invalid property.

3. Final Answer:

   @Injectable({ scope: Scope.TRANSIENT }) -> Option C

4. Quick Check:

   Use Scope.TRANSIENT enum for transient scope [OK]

Hint: Use Scope.TRANSIENT enum inside @Injectable decorator [OK]

Common Mistakes:

• Using string 'transient' instead of Scope enum
• Confusing transient with request scope
• Using invalid decorator properties

3. Consider this NestJS service with transient scope:

@Injectable({ scope: Scope.TRANSIENT })
export class MyService {
  id = Math.random();
}

If this service is injected twice in the same controller, what will be true about the id values?

medium

A. Both injections share the same id value.

B. The service will throw an error on multiple injections.

C. The id value is always zero.

D. Each injection has a different id value.

Solution

1. Step 1: Understand transient scope behavior

   Transient scope creates a new instance every time the service is injected, so each injection gets a fresh object.

2. Step 2: Apply to the id property

   Since id is set to a random number on instance creation, each injection will have a different id.

3. Final Answer:

   Each injection has a different id value. -> Option D

4. Quick Check:

   Transient scope = new instance per injection [OK]

Hint: Transient scope means new instance each injection [OK]

Common Mistakes:

• Assuming transient shares instance like default
• Thinking id is constant or zero
• Expecting errors on multiple injections

4. You set a service to request scope but notice it behaves like a singleton. What is the most likely cause?

medium

A. The controller injecting the service is not handling HTTP requests.

B. The service was not decorated with @Injectable.

C. The service scope was set incorrectly using a string instead of Scope.REQUEST.

D. The service is injected only once in the entire app.

Solution

1. Step 1: Understand request scope requirements

   Request scope creates a new instance per HTTP request, so it only works if the provider is injected in a context handling requests.

2. Step 2: Analyze the controller context

   If the controller is not handling HTTP requests (e.g., injected in a service or singleton), the request scope behaves like singleton.

3. Final Answer:

   The controller injecting the service is not handling HTTP requests. -> Option A

4. Quick Check:

   Request scope needs HTTP request context [OK]

Hint: Request scope needs HTTP request context to work [OK]

Common Mistakes:

• Forgetting request scope needs HTTP context
• Confusing decorator absence with scope behavior
• Assuming string scope works like enum

5. You have a service with request scope injected into a transient-scoped service, which is then injected into a controller. How many instances of the request-scoped service are created per HTTP request?

hard

A. One instance per HTTP request.

B. One instance per injection of the transient service.

C. One instance per controller instance.

D. Multiple instances per HTTP request depending on injections.

Solution

1. Step 1: Understand request scope lifetime

   Request-scoped services create one instance per HTTP request regardless of how many times they are injected.

2. Step 2: Analyze injection chain

   Even if injected into a transient service (new instance per injection), the request-scoped service instance remains the same within the same HTTP request.

3. Final Answer:

   One instance per HTTP request. -> Option A

4. Quick Check:

   Request scope = one instance per HTTP request [OK]

Hint: Request scope always one instance per HTTP request [OK]

Common Mistakes:

• Thinking transient causes multiple request-scoped instances
• Confusing transient and request scope lifetimes
• Assuming controller scope affects request-scoped service count