Provider scope (default, request, transient) in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a provider is set to default scope in NestJS?

Consider a NestJS service provider with the default scope. What is the behavior of this provider when injected into multiple components?

NestJS

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

@Injectable()
export class MyService {
  id = Math.random();
}

// This service is injected into two different controllers or providers.

A A new instance of MyService is created every time it is injected.

B A new instance of MyService is created for each HTTP request.

C A single instance of MyService is shared across the entire application.

D MyService instances are created only once per module.

💡 Hint

Default scope means the provider is a singleton by default.

In NestJS, providers with default scope are singletons. This means only one instance is created and shared across the whole app.

❓ component_behavior

intermediate

How does a request-scoped provider behave in NestJS?

If a provider is set with request scope, what happens when multiple HTTP requests use this provider?

NestJS

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

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

// This service is injected into controllers handling HTTP requests.

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

B A single instance is shared across all requests.

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

D Instances are created once per module load.

💡 Hint

Request scope means one instance per HTTP request.

Request-scoped providers create a new instance for each incoming HTTP request, ensuring isolated state per request.

❓ component_behavior

advanced

What is the behavior of a transient-scoped provider in NestJS?

A provider is marked with transient scope. What happens when it is injected multiple times in the same request?

NestJS

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

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

// Injected multiple times in the same request or component.

A A single instance is shared per HTTP request.

B A new instance is created every time the provider is injected.

C A single instance is shared across the entire app.

D Instances are created once per module.

💡 Hint

Transient scope means no instance sharing at all.

Transient providers create a new instance every time they are injected, even within the same request or component.

❓ state_output

advanced

What will be the output of the following NestJS provider instances' IDs?

Given these providers with different scopes, what will be the output of their id properties when injected twice in the same request?

NestJS

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

@Injectable()
export class DefaultService {
  id = Math.random();
}

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

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

// Assume these are injected twice in the same request and their ids logged.

A DefaultService ids are same, RequestService ids are same, TransientService ids are different.

B All three services have different ids each time they are injected.

C DefaultService ids same, RequestService ids differ, TransientService ids same.

D DefaultService ids differ, RequestService ids differ, TransientService ids are same.

💡 Hint

Think about how many instances each scope creates per injection or request.

Default scope creates one instance shared everywhere, so ids are same. Request scope creates one instance per request, so ids same within request. Transient creates new instance every injection, so ids differ.

❓ lifecycle

expert

Which provider scope causes the most frequent constructor calls in NestJS?

Consider a provider injected multiple times in various parts of an app. Which scope leads to the highest number of constructor executions?

A Singleton scope

B Request scope

C Default scope

D Transient scope

💡 Hint

Think about how often new instances are created for each scope.

Transient scope creates a new instance every injection, causing the constructor to run most frequently.

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