API with NestJS #6. Looking into dependency injection and modules

Express JavaScript NestJS TypeScript

NestJS strives to focus on the maintainability and testability of the code. To do so, it implements various mechanisms such as the Dependency Injection. In this article, we inspect how NestJS can resolve dependencies by looking into the output of the TypeScript compiler. We also strive to understand the modular architecture that NestJS is built with.

You can find the code from this series in this repository.

Reasons to implement Dependency Injection

You might be familiar with my TypeScript Express series. It adopted a rather simplistic approach to resolving dependencies.

There are a few drawbacks to the above, unfortunately. Every time we create an instance of the , we also create a new  . If we use the above approach in all of our controllers that need the  , each of them receives a separate instance. It might become hard to maintain over time.

Also, testability suffers. While it is possible to mock the   before the initialization of the above controller, it is a solution not perceived as ideal.

One of the SOLID principles is called the Inversion of Control (IoC). It states that high-level modules should not depend on the low-level modules. A straightforward way to achieve that is to create instances of dependencies first, and then provide them through a constructor.

If you want to know more about SOLID, check out Applying SOLID principles to your TypeScript code

While doing the above helps us overcome the mentioned issues, it is far from convenient. This is why NestJS implements a Dependency Injection mechanism that provides all of the necessary dependencies automatically.

Dependency Injection in NestJS under the hood

Let’s look at a similar controller that we’ve built in the third part of this series.

Thanks to using the  , we don’t need to asign the   in the body of the constructor.

The   decorator, among other things, ensures that the metadata about our class is saved. The   decorator also does this.

TypeScript compiler emits the metadata that NestJS can later use to figure out what dependencies do we need. Let’s inspect the output of the  .

The   is a key describing parameter type metadata. Thanks to it, we can obtain an array of references to classes that we need in the constructor of the  . We can perceive it as extracting the dependencies of the   at the compile time. NestJS uses the reflect-metadata package under the hood to work with the above metadata.

When a NestJS application starts, it resolves all the metadata the  needs. It might get quite complex under the hood, as it can deal with circular dependencies, for example.

If you want to dig deeper into how NestJS supplies the required dependencies, check out this talk by Kamil Myśliwiec, the creator of NestJS


A module is a part of our application that holds functionalities that revolve around a particular feature.

Every NestJS application has a root module. It serves as a starting point for NestJS when creating an application graph.


NestJS uses the root module to resolve other modules along with their dependencies. For example, we have the   that takes care of the authentication in our application. We create it in the third part of this series to handle the process of registering and verifying users.

As you can see from the   directory, a module can contain many things. In the above case, it wraps the controller, service, and some other files connected to the authentication process.

During authentication, we also need to read and create users. To encapsulate this process, we created a separate  . This shows that the modules are useful in dividing our app into pieces that work together.

Let’s inspect how we can use the   within the  . To do so, we first need to look into the  .


The crucial part here are the   and   arrays.

A provider is something that can inject dependencies. An example of such is a service. We put the   into the   array of the   to state that it belongs to that module.

As you can see above, a module can also import other modules. By putting the   into the   array, we indicate that the module exposes it. We can think of it as a public interface of a module.


Now, when we import the  , we have access to all of the exported providers. Thanks to that, we can use   within the  .

The significant thing is that in NestJS, modules are singletons. It means that the instance of the  is shared across all modules. The above would be especially crucial when considering techniques like in-memory caching.

The @Global() decorator

Although creating global modules might be discouraged and perceived as a bad design decision, it definitely is possible.

When we want a set of providers to be available everywhere, we can use the   decorator.

Now, we don’t need to import the   to use the  .

We should register a global module only once, and the best place for that is the root module.


In this article, we’ve dug deeper into how NestJS works with modules and how it resolves their dependencies. We’ve inspected a bit on what principles the Dependency Injection works in Nest. Learning about some of the inner mechanisms in the framework can help us to understand it better and, therefore, create a more sophisticated application structure.

Series Navigation<< API with NestJS #5. Serializing the response with interceptorsAPI with NestJS #7. Creating relationships with Postgres and TypeORM >>
Notify of