No NestJS, praticamente toda a arquitetura do framework gira em torno de um conceito central: a inversão de controle através da injeção de dependência. Quando alguém realmente entende isso, começa a entender por que o NestJS funciona da maneira que funciona, por que os módulos existem, por que usamos providers, e por que quase tudo no framework depende do container interno do Nest.
O primeiro conceito importante é entender o problema que a injeção de dependência resolve.
Imagine uma classe qualquer, por exemplo um service responsável por criar usuários. Esse service precisa salvar informações no banco, então ele precisa de um repository para persistir as informações. A forma mais simples e direta de fazer isso seria a própria classe criar sua dependência internamente:
classe UserService {
private repository = new UserRepository();
}
Isso funciona, mas cria um problema importante: a classe fica acoplada diretamente à implementação concreta da dependência. O UserService passa a ser responsável tanto pela sua lógica quanto pela criação das coisas que ele precisa para funcionar.
Esse acoplamento gera vários problemas. O primeiro é que trocar implementações fica difícil. Se amanhã quisermos substituir esse UserRepository por outra implementação, precisará altera o código interno do UserService. Outro problema é a testabilidade, como a dependência é criada dentro da própria classe, fica muito mais difícil de mockar ou substituir essa implementação em testes.
É exatamente ai que entra a injeção de dependência.
Com DI, a classe deixa de criar suas próprias dependências e passar apenas a recebê-las:
class UserService {
constructor(
private readonly repository: UserRepository,
) {}
}
Agora UserService não sabe mais como o repository foi criado. Ele apenas recebe algo pronto pra usar. Isso reduz drasticamente o acoplamento da aplicação.
Mas isso gera outra pergunta importante: se a classe não cria suas próprias dependências, quem cria?
No NestJS, quem faz isso é o container de injeção de dependências, também chamado de IoC Container (Inversion of Control Container).
A inversão de controle significa exatamente isso: a responsabilidade de controlar a criação das dependências sai da classe e passa ser responsabilidade de um sistema externo, no caso, o container do NestJS.
Quando a aplicação inicia, o Nest percorre todos os módulos da aplicação, analisando os providers registrados e começa a montar internamente um grafo de dependências. Ele identifica quais classes dependem de quais outras classes e cria tudo na ordem correta.
Por isso, quando vamos registrar algo no array de providers dentro do módulo, você está basicamente dizendo ao Nest:
"Essa classe pode ser criada e gerenciada pelo container"
Exemplo:
@Module({
providers: [UserService]
})
export class UserModule {}
Nesse momento, o Nest registra UserService dentro do container interno.
O decorator @Injectable() complementa isso. Ele marca a classe como compatível com o sistema de DI do Nest e permite que framework colete metadata sobra ela, especialmente os tipos presentes no construtor.
Então quando o Nest encontra algo assim:
@Injectable()
export class UserService {
contructor(
private readonly repository: UserRepository,
) {}
}
ele consegue entender automaticamente que, para criar o UserService, primeiro precisa encontrar ou criar uma instância de UserRepository.
Se userRepository também estiver registrado como provider, o Nest resolve a dependência automaticamente
@Module({
providers: [UserRepository, UserService],
})
O fluxo interno do Nest fica mais ou menos assim:
- o Nest encontra UserService e UserRepository registrados como providers dentro do módulo;
- ao processar o UserService, o Nest lê o construtor da classe; a. utiliza o Reflection Metadata gerado pelo TypeScript para identificar os tipos declarados no constructor; b. descobre quais dependências precisam ser resolvidas, como UserRepository;
- o container de DI procura essas dependências entre os providers registrados (porque ela pode já ter sido instanciada);
- o Nest instancia primeiro as dependências necessárias;
- após resolver todas as dependências, cria a instância do UserService já com tudo injetado;
- as instâncias criadas são armazenadas no container intenro do NestJS;
- sempre que alguma parte da aplicação solicitar esses providers novamente, o Nest reutiliza as instâncias já existentes (singleton por padrão)
Por padrão, os providers do Nest são singleton. Isso significa que o Nest cria apenas uma instância daquela classe e reutiliza essa mesma instância em toda a aplicação sempre que necessário.
Então, se dez services diferentes dependerem de UserRepository, todos receberão exatamente a mesma instância. Isso é extremamente importante porque:
- reduz o consumo de memória;
- evita recriação desnecessária de objetos;
- mantém estados compartilhados quando necessários;
- mantém performance;
O container do Nest funciona basicamente como um grande registro interno de instâncias
Conceitualmente, seria algo parecido como:
Map<Token, Instance>
Onde o token normalmente é a própria classe, então quando fazemos:
module.get(UserService)
O Nest procura internamente se existe uma instância registrada para UserService, se existir irá retornar, se não existir, cria resolvendo todas as dependências.
Os módulos também são fundamentais nessa arquitetura. Eles funcionam como organizadores de contexto. Um módulo define quais providers pertencem á aquele contexto e quais deles podem ser compartilhados com outros módulos.
Quando um provider é exportado:
@Module({
providers: [UserService],
exports: [UserService],
})
ele pode ser utilizado por outros módulos que importarem o mesmo.
Sem exportar, o provider fica privado ao módulo (é semelhante a métodos de acesso de uma classe, por exemplo).
Outro detalhe muito importante é entender que o Nest resolve dependências observando o construtor das classes. Isso acontece graças ao reflection metadata do TypeScript. O Nest lê os tipos declarados no construtor e usa essas informações para saber o que precisa injetar.
É por isso que normalmente você não precisa escrever manualmente algo como:
@Inject(UserRepository)
Porque o Nest consegue inferir automaticamente.
Conforme você vai evoluindo no NestJS, começa a entender e perceber que praticamente tudo no framework é provider
- services;
- repositories;
- guards;
- interceptors;
- pipes;
- strategies;
- gateways;
- filters;
Todos são apenas classes gerenciadas pelo container de DI
No final das contas, dominar injeção de dependência no NestJS significa mudar sua forma de pensar sobre arquitetura.
Você deixa de pensar: "Essa classe cria o que precisa".
E passa a pensar: "Essa classe declara o que precisa, e o container resolve tudo automaticamente"
Esse é um dos motivos pelos quais aplicações NestJS conseguem escalar tão bem em organizações, desacoplando as coisas e aumentando a testabilidade.
Top comments (3)
Good breakdown. The main win is just declare deps, don’t build them - that’s where Nest really starts to make sense.
I’d slightly push back on everything is a provider since in practice module boundaries and circular deps matter more than the abstraction.
Reflection-based injection is great until you start doing more dynamic setups and it gets less predictable.
You usually handling circular deps with forwardRef or just redesigning the module?
From the moment I started working and studying more about Nest, I heard that circular dependencies aren't a best practice, but sometimes they are necessary.
In this article I also didn't mention dynamic modules, but I believe that would be the natural next step to study after this. But I'd like to know what your approach would be in those cases?
Yeah, I’d still try to break the cycle first by splitting the module or moving shared stuff into a separate one.
forwardRefworks, but I only reach for it when the design is already boxed in. Dynamic modules are useful when the wiring really has to happen at runtime, just keep them as simple as you can.