Understanding Providers and Dependency Injection in NestJS

When I first started working with NestJS, registering providers (and controllers) inside a module felt like nothing more than a chore.

It was one of those things I did because “that’s just how Nest is designed.”

Even after I learned that modules exist to build an application graph, which it uses internally to resolve relationships and dependencies between modules and providers, the idea still felt vague and abstract. I understood what was happening, but not really why it worked the way it did.

Recently, I decided to take a deeper dive into how providers are registered and how Nest actually injects them. It turned out to be far more interesting than I expected.

Here’s what I learned.

First, let’s understand what Dependency Injection is.

Wikipedia defines Dependency Injection(DI) as:

Dependency Injection is a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally.

Let’s look at a simple example.

Imagine a restaurant application. When a user’s order is ready for pickup, a notification needs to be sent.

class OrderService {
  // code operating over orders

  const notificationService = new NotificationService()
  notificationService.notify(userId, message)

  // ...
}

Here, OrderServicehandles order-related logic, and NotificationServicehandles notifications.

However, because NotificationServiceis instantiated directly inside OrderServiceusing new, this is not dependency injection.

Now compare that with this:

class OrderService {
  constructor(
    private readonly notificationService: NotificationService,
  ) {}

  // code operating over orders
  notificationService.notify(userId, message)

  // ...
}

This is dependency injection.

OrderService no longer cares about how NotificationService is created. It simply declares that it needs one, and something else provides it. That instance can also be reused or cached if the configuration is the same in multiple places.

Why Dependency Injection?

Dependency Injection helps by:

• Reducing coupling between classes
• Making testing easier (you can inject mock dependencies)
• Encouraging modular, maintainable code

How Dependency Injection Works in NestJS

Alright, enough theory, this is where things start to get interesting.

In NestJS, the basic flow looks something like this:

1. Define a provider using @Injectable()
2. Register that provider with Nest
3. Ask Nest to inject it using constructor-based injection

Registration usually happens in a module:

@Module({
  providers: [DemoService],
  controllers: [DemoController],
})
export class DemoModule {}

At this point, Nest becomes responsible for creating and managing instances of DemoService.

Nest’s IoC Container (The Missing Piece)

NestJS uses an IoC (Inversion of Control) container to manage dependencies.

You can think of this container as a key-value registry:

• Keys are called tokens
• Values describe how to create or retrieve a dependency

When we write:

providers: [DemoService]

Nest internally expands it into a standard provider definition:

providers: [
  {
    provide: DemoService,
    useClass: DemoService,
  },
]

In this case:

• The token is DemoService (the class itself)
• useClass tells Nest which class to instantiate when that token is requested.

So when Nest encounters:

constructor(private readonly demoService: DemoService) {}

1. Nest looks up the DemoService token in the IoC container
2. It finds the matching provider record
3. It resolves the provider (useClass in this case)
4. The instance is created (or reused, since providers are singletons by default)
5. The resolved instance is injected into the class

A Quick Note on useValue and useFactory

useClass is the most common way to define a provider, but it’s not the only one.

• useValue lets you inject a constant or pre-created object

  Useful for configuration values, feature flags, or mocks.

• useFactory allows you to create a value dynamically

  Nest runs a function and injects whatever it returns.

All three (useClass, useValue, and useFactory) exist for the same reason:

they tell the IoC container how to resolve a token when it’s requested.