Bird
Raised Fist0
NestJSframework~10 mins

Provider scope (default, request, transient) in NestJS - Interactive Code Practice

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to set the provider scope to default (singleton).

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

@Injectable({ scope: [1] })
export class MyService {}
Drag options to blanks, or click blank then click option'
AScope.DEFAULT
BScope.REQUEST
CScope.TRANSIENT
DScope.SINGLETON
Attempts:
3 left
💡 Hint
Common Mistakes
Using Scope.REQUEST or Scope.TRANSIENT when singleton is needed.
Using a non-existent Scope.SINGLETON value.
2fill in blank
medium

Complete the code to set the provider scope to request-scoped.

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

@Injectable({ scope: [1] })
export class RequestService {}
Drag options to blanks, or click blank then click option'
AScope.REQUEST
BScope.TRANSIENT
CScope.DEFAULT
DScope.SINGLETON
Attempts:
3 left
💡 Hint
Common Mistakes
Confusing request scope with transient or default scopes.
Using Scope.SINGLETON which does not exist.
3fill in blank
hard

Fix the error in the provider scope declaration to make it transient.

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

@Injectable({ scope: [1] })
export class TransientService {}
Drag options to blanks, or click blank then click option'
AScope.DEFAULT
BScope.REQUEST
CScope.TRANSIENT
DScope.SINGLETON
Attempts:
3 left
💡 Hint
Common Mistakes
Using Scope.REQUEST instead of Scope.TRANSIENT.
Using Scope.DEFAULT which is singleton.
4fill in blank
hard

Fill both blanks to create a request-scoped provider and inject it into a controller.

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

@Injectable({ scope: [1] })
export class UserService {
  getUser() {
    return 'User Data';
  }
}

@Controller('users')
export class UserController {
  constructor(private readonly userService: [2]) {}

  @Get()
  getUser() {
    return this.userService.getUser();
  }
}
Drag options to blanks, or click blank then click option'
AScope.REQUEST
BUserService
CScope.TRANSIENT
DUserController
Attempts:
3 left
💡 Hint
Common Mistakes
Using the controller class as the injected type.
Setting the wrong scope for the provider.
5fill in blank
hard

Fill all three blanks to create a transient provider, inject it, and call its method in a controller.

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

@Injectable({ scope: [1] })
export class LoggerService {
  log(message: string) {
    return `Log: ${message}`;
  }
}

@Controller('logs')
export class LogController {
  constructor(private readonly logger: [2]) {}

  @Get()
  getLog() {
    return this.logger.[3]('Hello');
  }
}
Drag options to blanks, or click blank then click option'
AScope.TRANSIENT
BLoggerService
Clog
DScope.REQUEST
Attempts:
3 left
💡 Hint
Common Mistakes
Using request scope instead of transient.
Calling a non-existent method on the provider.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard