Overview of Dependency Injection

Since Typescript 1.5 introduces the notion of the decorator, you can do meta-programing using the added metadata provided by using a decorator on different objects or properties, such as class, function, function parameters or class property. The meta-programing is the ability to write some code or program using the metadata describing an object. This type of program allows you to modify the functioning of a program using its own metadata. In our case this metadata is of interest to us, because it helps inject some object into another object, whose name is Dependency Injection.

By using the decorator, you can add metadata on any object or property linked to those decorators. This will define, for example, the type of object that takes the decorator, but it can also define all of the parameters needed by a function that are described in its metadata. To get or define metadata on any object, you can also use the reflect-metadata library in order to manipulate them.

export class UserService() {
    private users: Array<User> = [{
        id: 1,
        email: 'userService1@email.com',
        password: 'pass'
    ]};

    public findOne({ where }: any): Promise<User> {
        return this.users
        .filter(u => {
            return u.email === where.email &&
            u.password === where.password;
        });
    }
}

export class AuthenticationService {
    public userService: UserService;

    constructor() {
        this.userService = new UserService();
    }

    async validateAUser(payload: { email: string; password: string }): Promise<boolean> {
        const user = await this.userService.findOne({
            where: payload
        });
        return !!user;
    }
}

const authenticationService = new AuthenticationService();

// Rewritted AuthenticationService
export class AuthenticationService {
    /* 
       Declare at the same time the public 
       properties belongs to the class
    */
    constructor(public userService: UserService) { }
}

// Now you can instanciate the AutheticationService like that
const userService = new UserService();
const authenticationService = new AuthenticationService(userService);

@Injectable()
export class UserService { /*...*/ }

@Injectable()
export class AuthenticationService {
    constructor(private userService: UserService) { }
}

export Component = () => {
    return (target: Type<object>) => {
        CustomInjector.set(target);
    };
}

export const CustomInjector = new class {
  protected services: Map<string, Type<any>> = new Map<string, Type<any>>();

  resolve<T>(target: Type<any>): T {
    const tokens = Reflect.getMetadata('design:paramtypes', target) || [];
    const injections = tokens.map(token => CustomInjector.resolve<any>(token));
    return new target(/*...*/injections);
  }

  set(target: Type<any>) {
    this.services.set(target.name, target);
  }
};

const authenticationService = CustomInjector.resolve<AuthenticationService>(AuthenticationService);
const isValid = authenticationService.validateUser(/* payload */);

Nest.js Dependency Injection

From the @nestjs/common you have access to the decorators provided by the framework and one of them is the @Module() decorator. This decorator is the main decorator to build all of your modules and work with the Nest.js Dependency Injection system between them.

Your application will have at least one module, which is the main one. The application can use only one module (the main one) in the case of a small app. Nonetheless, as your app grows, you will have to create several modules to arrange your app for the main module.

From the main module, Nest will know all of the related modules that you have imported, and then create the application tree to manage all of the Dependency Injections and the scope of the modules.

To do this, the @Module() decorator respects the ModuleMetadata interface, which defines the properties allowed to configure a module.

export interface ModuleMetadata {  
    imports?: any[];  
    providers?: any[];  
    controllers?: any[];  
    exports?: any[];
    modules?: any[]; // this one is deprecated.
}

To define a module, you have to register all of the services stored in providers that will be instantiated by the Nest.js injector, as well as the controllers that can inject the providers, which are services, registered into the module or those exported by another module through the exports property. In such a case, these have to be registered in imports.

It is not possible to access an injectable from another module if it has not been exported by the module itself, and if the exporting module hasn’t been imported into the concerned module, which has to use the external services.

How does Nest.js create the Dependency injection tree?

In the previous section, we talked about the main module, generally called AppModule, which is used to create the app from NestFactory.create. From here, Nest.js will have to register the module itself, and it will also go through each module imported to the main module.

Nest.js will then create a container for the entire app, which will contain all of the module, globalModule, and dynamicModuleMetadata of the entire application.

After it has created the container, it will initialize the app and, during the initialization, it will instantiate an InstanceLoader and a DependenciesScanner -> scanner.ts, via which Nest.js will have the possibility to scan every module and metadata related to it. It does this to resolve all of the dependencies and generate the instance of all modules and services with their own injections.

If you want to know the details of the engine, we recommend that you go deep into the two classes: InstanceLoader and DependenciesScanner.

To have a better understanding of how this works, take a look at an example.

Imagine that you have three modules:

• ApplicationModule
• AuthenticationModule
• UserModule

The app will be created from the ApplicationModule:

@Module({
    imports: [UserModule, AuthenticationModule]
})
export class ApplicationModule {/*...*/}

This imports the AuthenticationModule:

@Module({
    imports: [UserModule],
    providers: [AuthenticationService]
})
export class AuthenticationModule {/*...*/}

@Injectable()
export class AuthenticationService {
    constructor(private userService: UserService) {}
}

And the UserModule:

@Module({
    providers: [UserService],
    exports: [UserService]
})
export class UserModule {/*...*/}

@Injectable()
export class UserService {/*...*/}

In this case, the AuthenticationModule must import the UserModule, which exports the UserService.

We have now built our application’s architecture module and have to create the app, which will be allowed to resolve all of the dependencies.

const app = await NestFactory.create(ApplicationModule);

Essentially, when you create the app, Nest.js will:

• Scan the module.
  • Store the module and an empty scope array (for the main module). The scope will then be populated with the module, which imports this scanned module.
  • Look at the related modules through the modules metadata.
• Scan for the modules dependencies as services, controllers, related modules, and exports to store them in the module.
• Bind all of the global modules in each module to the related module.
• Create all of the dependencies by resolving the prototype, creating an instance for each one. For dependencies that have dependencies themselves, Nest.js will resolve them in the same way and include these in the previous level.

What about the global module?

Nest.js also provides a @Global() decorator, allowing Nest to store them in a global Set of modules, which will be added to the related Set of the module concerned.

This type of module will be registered with the __globalModule__ metadata key and added to the globalModule set of the container. They will then be added to the related Set of the module concerned. With a global module, you are allowed to inject components from the module into another module without importing it into the targeted module. This avoids having to import a module, which is possibly used by all of the modules, into all of the modules.

Here is an example:

@Module({
    imports: [DatabaseModule, UserModule]
})
export class ApplicationModule {/*...*/}

@Global()
@Module({
    providers: [databaseProvider],
    exports: [databaseProvider]
})
export class DatabaseModule {/*...*/}

@Module({
    providers: [UserService],
    exports: [UserService]
})
export class UserModule {/*...*/}

@Injectable()
export class UserService {
    // SequelizeInstance is provided by the DatabaseModule store as a global module
    constructor(@Inject('SequelizeInstance') private readonly sequelizeInstance) {}
}

With all the previous information, you should now be familiar with the mechanism of the Nest.js dependency injection and have a better understanding of how they work together.

The difference between Nest.js and Angular DI

Even if Nest.js is widely based on Angular, there is a major difference between them. In Angular, each service is a singleton, which is the same as Nest.js, but there is a possibility to ask Angular to provide a new instance of the service. To do that in Angular, you can use the providers property of the @Injectable() decorator to have a new instance of a provider registered in the module and available only for this component. That can be useful to have to avoid overwriting some properties through different components.

Summary

So to recap, we have seen in this chapter how it was unflexible and hard to test an object without using the Dependecy Injection. Also, we have learned more about the evolution of the method to implement the dependencies into the dependent, first by implementing the dependencies into the dependent, then changing the method by passing them manually into the constructor to arrive with the injector system. This then resolves the dependencies, injecting them in the constructor automatically by resolving a tree, which is how Nest.js uses this pattern.

In the next chapter we will see how Nest.js uses TypeORM, an Object Relational Mapping (ORM) that works with several different relational databases.