What is a provider in NestJS?
Any class decorated with @Injectable() that can be injected via the DI container is a provider. Services, repositories, factories, helpers, and guards are all providers. They are registered in a module's providers array and instantiated by the NestJS IoC container.
The main idea of a provider is that it can be injected as a dependency. NestJS manages the lifecycle and instantiation of providers through its IoC (Inversion of Control) container.
- 1
Services — contain business logic.
- 2
Repositories — handle data access.
- 3
Guards — handle authorization.
- 4
Interceptors — transform requests/responses.
- 5
Pipes — validate and transform input data.
- 6
Factories — create and configure instances.
Scenario Questions
0-2 years experience
- 1How would you register a simple service as a provider in a NestJS module?
- 2If you forget to add a provider to the module's providers array, what runtime error do you see when trying to inject it?
- 3Show me how you would inject a provider into a controller using constructor injection.
2-5 years experience
- 1You need to replace a third‑party library with a mock for testing; how would you configure a custom provider to achieve that?
- 2During a feature rollout, injecting a provider throws 'Nest can't resolve dependencies' – what steps would you take to debug?
- 3Explain why you might use useFactory instead of useClass when defining a provider, and give an example where useFactory is preferable.
5-8 years experience
- 1Our microservice must share a single database connection across many modules without creating multiple connections; how would you design a provider to handle this efficiently?
- 2When scaling to thousands of requests, what are the performance implications of using request‑scoped providers versus singleton providers?
- 3If you need to conditionally provide different implementations based on environment variables, how would you structure the provider registration to keep the code maintainable?
8+ years experience
- 1We are migrating a legacy NestJS monolith to a modular architecture; how would you refactor existing providers to avoid circular dependencies and support independent deployment?
- 2Across multiple teams, you need a shared logging provider that can be overridden per service; what design patterns and NestJS features would you employ to ensure extensibility and versioning?
- 3Discuss the trade‑offs of using dynamic modules with custom providers for feature toggles versus a centralized configuration service.
Follow-up Questions
- What is the default lifecycle scope for a NestJS provider?
- How does Nest handle circular dependencies between providers?
- When would you choose a request‑scoped provider over a singleton?