Custom providers in NestJS

Introduction

Custom providers let you tell NestJS how to create or find a value or service. This helps you control what your app uses in different places.

When you want to use a class or value that NestJS does not create automatically.

When you want to replace a service with a different version for testing or special cases.

When you want to provide a simple value like a string or number to parts of your app.

When you want to create a service with special setup steps before NestJS uses it.

Syntax

NestJS

providers: [
  {
    provide: TOKEN_OR_CLASS,
    useClass: ClassToUse,
  },
  {
    provide: TOKEN_OR_CLASS,
    useValue: someValue,
  },
  {
    provide: TOKEN_OR_CLASS,
    useFactory: () => {
      return new SomeClass();
    },
  },
  {
    provide: TOKEN_OR_CLASS,
    useExisting: ExistingProvider,
  }
]

provide is the token or class name NestJS uses to find this provider.

You can use useClass, useValue, useFactory, or useExisting to tell NestJS how to get the value.

Examples

This provides a simple number value 42 when 'MY_VALUE' is requested.

NestJS

providers: [
  {
    provide: 'MY_VALUE',
    useValue: 42,
  }
]

This tells NestJS to use MyCustomService whenever MyService is requested.

NestJS

providers: [
  {
    provide: MyService,
    useClass: MyCustomService,
  }
]

This uses a factory function to provide a config object.

NestJS

providers: [
  {
    provide: 'CONFIG',
    useFactory: () => ({
      host: 'localhost',
      port: 3000,
    }),
  }
]

This creates an alias 'ALIAS' that points to the same instance as ExistingService.

NestJS

providers: [
  ExistingService,
  {
    provide: 'ALIAS',
    useExisting: ExistingService,
  }
]

Sample Program

This example shows how to create a custom provider named 'Logger' that uses CustomLoggerService instead of the default LoggerService. The AppService asks for 'Logger' and gets the custom version. When run() is called, it logs with the custom prefix.

NestJS

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

@Injectable()
class LoggerService {
  log(message: string) {
    console.log('LOG:', message);
  }
}

@Injectable()
class CustomLoggerService {
  log(message: string) {
    console.log('CUSTOM LOG:', message);
  }
}

@Injectable()
class AppService {
  constructor(@Inject('Logger') private logger: LoggerService) {}

  run() {
    this.logger.log('App is running');
  }
}

@Module({
  providers: [
    AppService,
    {
      provide: 'Logger',
      useClass: CustomLoggerService,
    },
  ],
})
export class AppModule {}

// Simulate NestJS bootstrap and usage
async function bootstrap() {
  // Manually create instances to simulate NestJS DI
  const logger = new CustomLoggerService();
  const appService = new AppService(logger);
  appService.run();
}

bootstrap();

Important Notes

Custom providers let you swap implementations without changing the code that uses them.

Use useValue for simple constants, useClass for classes, useFactory for dynamic creation, and useExisting to alias providers.

Always provide a unique token or class in provide to avoid conflicts.

Summary

Custom providers control how NestJS creates or finds a service or value.

You can provide classes, values, factories, or aliases using different keys.

This helps make your app flexible and easy to test.

Practice

1. What is the main purpose of a custom provider in NestJS?

easy

A. To manage database connections automatically

B. To define routes for HTTP requests

C. To control how NestJS creates or finds a service or value

D. To handle user authentication and authorization

Solution

1. Step 1: Understand the role of providers in NestJS

   Providers are responsible for creating and managing services or values that can be injected into other parts of the app.

2. Step 2: Identify what custom providers do

   Custom providers let you control exactly how NestJS creates or finds these services or values, making your app more flexible.

3. Final Answer:

   To control how NestJS creates or finds a service or value -> Option C

4. Quick Check:

   Custom provider purpose = control creation/finding [OK]

Hint: Custom providers control service creation or retrieval [OK]

Common Mistakes:

• Confusing providers with routing or middleware
• Thinking providers manage database or auth directly
• Assuming providers only register classes, not values or factories

2. Which of the following is the correct syntax to provide a custom value provider in a NestJS module?

easy

A. { provide: 'API_URL', useValue: 'https://api.example.com' }

B. { provide: 'API_URL', useClass: 'https://api.example.com' }

C. { provide: 'API_URL', useFactory: 'https://api.example.com' }

D. { provide: 'API_URL', useExisting: 'https://api.example.com' }

Solution

1. Step 1: Recall the syntax for value providers

   Value providers use the useValue key to assign a fixed value to a token.

2. Step 2: Check each option's correctness

   { provide: 'API_URL', useValue: 'https://api.example.com' } correctly uses useValue with a string value. Other options misuse useClass, useFactory, or useExisting which expect different types.

3. Final Answer:

   { provide: 'API_URL', useValue: 'https://api.example.com' } -> Option A

4. Quick Check:

   Value provider uses useValue = { provide: 'API_URL', useValue: 'https://api.example.com' } [OK]

Hint: Value providers always use 'useValue' key [OK]

Common Mistakes:

• Using useClass or useFactory for fixed values
• Confusing useExisting with useValue
• Putting string directly without useValue

3. Given the following provider configuration in a NestJS module:

{ provide: 'RANDOM_NUMBER', useFactory: () => Math.floor(Math.random() * 10) }

What will be the output if you inject 'RANDOM_NUMBER' twice in the same request?

medium

A. The same random number both times

B. Always zero because Math.random() is called once

C. An error because useFactory cannot be used this way

D. Two different random numbers between 0 and 9

Solution

1. Step 1: Understand provider scope and factory behavior

   By default, NestJS providers are singletons per application context, so the factory runs once and the result is reused.

2. Step 2: Analyze injection behavior

   Injecting 'RANDOM_NUMBER' twice in the same request returns the same value because the factory was called once at provider creation.

3. Final Answer:

   The same random number both times -> Option A

4. Quick Check:

   Singleton factory = same value injected [OK]

Hint: Default providers are singletons; factory runs once [OK]

Common Mistakes:

• Assuming factory runs on every injection
• Thinking useFactory causes errors without async
• Believing random number changes per injection

4. Consider this provider configuration:

{ provide: 'CONFIG', useFactory: () => ({ port: 3000 }) }

If you want to inject this provider but get an error "Nest can't resolve dependencies", what is the most likely cause?

medium

A. The token 'CONFIG' must be a class, not a string

B. The useFactory function must be async

C. You cannot use useFactory with object literals

D. The provider is missing from the module's providers array

Solution

1. Step 1: Check provider registration

   For NestJS to inject a provider, it must be registered in the module's providers array.

2. Step 2: Evaluate other options

   useFactory can be sync or async, tokens can be strings, and useFactory can return objects. The error usually means the provider is not registered.

3. Final Answer:

   The provider is missing from the module's providers array -> Option D

4. Quick Check:

   Missing provider registration = injection error [OK]

Hint: Always register providers in module's providers array [OK]

Common Mistakes:

• Assuming useFactory must be async
• Thinking tokens must be classes only
• Believing useFactory can't return objects

5. You want to create a custom provider that returns different database connection strings based on environment variables. Which approach correctly implements this using a factory provider in NestJS?

hard

A. { provide: 'DB_CONNECTION', useValue: process.env.NODE_ENV === 'prod' ? 'prod-db' : 'dev-db' }

B. { provide: 'DB_CONNECTION', useFactory: () => process.env.NODE_ENV === 'prod' ? 'prod-db' : 'dev-db' }

C. { provide: 'DB_CONNECTION', useClass: process.env.NODE_ENV === 'prod' ? ProdDbService : DevDbService }

D. { provide: 'DB_CONNECTION', useExisting: process.env.NODE_ENV === 'prod' ? 'ProdDbService' : 'DevDbService' }

Solution

1. Step 1: Understand dynamic value creation

   To choose a value based on environment variables at runtime, a factory provider is ideal because it runs code to decide the value.

2. Step 2: Evaluate each option

   { provide: 'DB_CONNECTION', useFactory: () => process.env.NODE_ENV === 'prod' ? 'prod-db' : 'dev-db' } uses useFactory with a function that returns the correct string based on process.env.NODE_ENV. { provide: 'DB_CONNECTION', useValue: process.env.NODE_ENV === 'prod' ? 'prod-db' : 'dev-db' } uses useValue which is static at module load time. Options C and D misuse useClass and useExisting with strings or conditions incorrectly.

3. Final Answer:

   { provide: 'DB_CONNECTION', useFactory: () => process.env.NODE_ENV === 'prod' ? 'prod-db' : 'dev-db' } -> Option B

4. Quick Check:

   Dynamic values need useFactory with runtime logic [OK]

Hint: Use useFactory for runtime-dependent values [OK]

Common Mistakes:

• Using useValue for dynamic environment-based values
• Misusing useClass or useExisting with strings
• Expecting useFactory to be static