O que são provedores customizados e tokens de injeção?

Question

Accepted Answer

Além de simples classes `@Injectable()`, NestJS suporta **provedores customizados** — formas flexíveis de definir o que é injetado — usando **tokens de injeção**. Isso permite injetar valores, configurar como instâncias são criadas, trocar implementações e injetar dependências que não são classes.

## Os quatro tipos de provedores customizados

```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 {}
```

## Tokens de injeção — para dependências que não são classes

```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
}
```

Como você não pode injetar uma interface ou um valor simples por tipo (eles não existem em tempo de execução), você usa um **token** (uma string ou `Symbol`) com `@Inject(token)` para injetá-lo. É assim que você injeta objetos de configuração, clientes de terceiros ou dependências tipadas por interface.

## useFactory — o mais poderoso (setup dinâmico e assíncrono)

```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` executa uma função (com dependências injetadas) para produzir o provedor — essencial para conexões, clientes ou qualquer coisa que necessite configuração em tempo de execução ou setup assíncrono.

## Trocando implementações (useClass) — flexibilidade e testes

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

Como consumidores dependem do token (`PaymentService`), você pode trocar a classe concreta — um serviço Stripe real em produção, um mock em testes — sem alterar nenhum código consumidor.

## Por que isso importa

Provedores customizados e tokens de injeção estendem a injeção de dependência do NestJS além de simples classes, oferecendo a flexibilidade necessária para aplicações do mundo real.

Entender isso é importante para vários cenários comuns: **injetar valores que não são classes** (objetos de configuração, constantes) via `useValue` e tokens string/Symbol (já que você não pode injetar interfaces ou valores simples por tipo); **criação dinâmica/assíncrona de provedores** via `useFactory` (a forma mais poderosa — criando conexões de banco de dados, clientes Redis ou instâncias de SDKs de terceiros configuradas a partir de valores em tempo de execução, com suas próprias dependências injetadas); e **trocar implementações** via `useClass` por trás de um token (habilitando implementações baseadas em ambiente e, crucialmente, **fácil mockagem em testes** — fornecer uma classe mock para um token sem tocar nos consumidores).

Essa flexibilidade é o que torna o DI do NestJS poderoso para arquitetura em produção e excelente testabilidade.

Conhecer os quatro tipos de provedores (`useClass`, `useValue`, `useFactory`, `useExisting`), como tokens de injeção funcionam para dependências que não são classes e quando recorrer a cada um é um passo importante além do DI básico — é assim que você conecta bancos de dados, serviços externos, configuração e dependências swappable/mockable da forma idiomática do NestJS, tornando isso um tópico frequentemente necessário e significativo arquiteturalmente em aplicações reais.