What are custom providers and injection tokens?

Question

IT Interview Practice · Accepted Answer

Beyond simple `@Injectable()` classes, NestJS supports **custom providers** — flexible ways to define what gets injected — using **injection tokens**. This lets you inject values, configure how instances are created, swap implementations, and inject non-class dependencies.

## The four custom provider types

```ts
@Module({
  providers: [
    // 1. useClass — standard (or swap the implementation behind a token)
    { provide: PaymentService, useClass: StripePaymentService },

// 2. useValue — inject a constant/object/mock (great for config and testing)
    { provide: "CONFIG", useValue: { apiKey: "abc", timeout: 5000 } },

// 3. useFactory — compute the provider dynamically (can use other deps)
    {
      provide: "DATABASE_CONNECTION",
      useFactory: async (config: ConfigService) => {
        return await createConnection(config.get("DB_URL"));   // async setup
      },
      inject: [ConfigService],        // dependencies for the factory
    },

// 4. useExisting — create an alias for an existing provider
    { provide: "ALIAS", useExisting: PaymentService },
  ],
})
export class AppModule {}
```

## Injection tokens — for non-class dependencies

```ts
// classes can be tokens directly (by type). For values/interfaces, use a string/Symbol token:
@Injectable()
export class PaymentProcessor {
  constructor(@Inject("CONFIG") private config: AppConfig) {}   // inject by token
}
```

Since you can't inject an interface or a plain value by type (they don't exist at runtime), you use a **token** (a string or `Symbol`) with `@Inject(token)` to inject it. This is how you inject configuration objects, third-party clients, or interface-typed dependencies.

## useFactory — the most powerful (dynamic, async setup)

```ts
// create a provider whose value depends on runtime config / async initialization
{
  provide: "REDIS_CLIENT",
  useFactory: (config: ConfigService) => new Redis(config.get("REDIS_URL")),
  inject: [ConfigService],
}
```

`useFactory` runs a function (with injected dependencies) to produce the provider — essential for connections, clients, or anything needing runtime configuration or async setup.

## Swapping implementations (useClass) — flexibility & testing

```ts
// inject a different implementation based on environment
{
  provide: PaymentService,
  useClass: process.env.NODE_ENV === "test" ? MockPaymentService : StripePaymentService,
}
```

Because consumers depend on the token (`PaymentService`), you can swap the concrete class — a real Stripe service in production, a mock in tests — without changing any consuming code.

## Why it matters

Custom providers and injection tokens extend NestJS's dependency injection beyond simple classes, giving you the flexibility needed for real-world applications.

Understanding them is important for several common scenarios: **injecting non-class values** (configuration objects, constants) via `useValue` and string/Symbol tokens (since you can't inject interfaces or plain values by type); **dynamic/async provider creation** via `useFactory` (the most powerful form — creating database connections, Redis clients, or third-party SDK instances configured from runtime values, with their own injected dependencies); and **swapping implementations** via `useClass` behind a token (enabling environment-based implementations and, crucially, easy **mocking in tests** — provide a mock class for a token without touching consumers).

This flexibility is what makes NestJS's DI powerful for production architecture and excellent testability.

Knowing the four provider types (`useClass`, `useValue`, `useFactory`, `useExisting`), how injection tokens work for non-class dependencies, and when to reach for each is an important step beyond basic DI — it's how you wire up databases, external services, configuration, and swappable/mockable dependencies the idiomatic NestJS way, making it a frequently-needed, architecturally-significant topic in real applications.

The four custom provider types

Injection tokens — for non-class dependencies

useFactory — the most powerful (dynamic, async setup)

Swapping implementations (useClass) — flexibility & testing

Why it matters

Related questions