Modules

Nest.js의 Modules에 대해 정리하였습니다.

---

< Modules >

The @Module( ) decorator provides metadata that Nest makes use of to organize the application structure.

A module is a class annotated with a @Module( ) decorator.

 

 

The @Module( ) decorator takes a single object whose properties describe the module:

providers	the providers that will be instantiated by the Nest injector and that may be shared at least across this module
controllers	the set of controllers defined in this module which have to be instantiated
imports	the list of imported modules that export the providers which are required in this module
exports	the subset of providers that are provided by this module and should be available in other modules which import this module. You can use either the provider itself or just its token (provide value)

 

 

---

< Feature Modules >

The CatsController and CatsService belong to the same application domain. As they are closely related, it makes sense to move them into a feature module. A feature module simply organizes code relevant for a specific feature, keeping code organized and establishing clear boundaries. This helps us manage complexity and develop with SOLID principles, especially as the size of the application and/or team grow.

 

Ex)

cats/cats.module.ts

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class CatsModule {}

 

app.module.ts

import { Module } from '@nestjs/common';
import { CatsModule } from './cats/cats.module';

@Module({
  imports: [CatsModule],
})
export class AppModule {}

 

 

---

< Shared Modules >

In Nest, modules are singletons by default, and thus you can share the same instance of any provider between multiple modules effortlessly.

 

 

Ex)

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService]
})
export class CatsModule {}

: Now any module that imports the CatsModule has access to the CatsService and will share the same instance with all other modules that import it as well.

 

 

---

< Modules Re-exporting >

As seen above, Modules can export their internal providers. In addition, they can re-export modules that they import.

 

Ex)

@Module({
  imports: [CommonModule],
  exports: [CommonModule],
})
export class CoreModule {}

: the CommonModule is both imported into and exported from the CoreModule, making it available for other modules which import this one.

 

 

---

< Global Modules >

If you have to import the same set of modules everywhere, it can get tedious.

When you want to provide a set of providers which should be available everywhere out-of-the-box (e.g., helpers, database connections, etc.), make the module global with the @Global( ) decorator.

 

Ex)

import { Module, Global } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Global()
@Module({
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService],
})
export class CatsModule {}

: The @Global( ) decorator makes the module global-scoped. Global modules should be registered only once, generally by the root or core module. In the above example, the CatsService provider will be ubiquitous, and modules that wish to inject the service will not need to import the CatsModule in their imports array.

 

< HINT >
Making everything global is not a good design decision. Global modules are available to reduce the amount of necessary boilerplate. The  imports  array is generally the preferred way to make the module's API available to consumers.

 

 

---

Reference : https://docs.nestjs.com/modules

Documentation | NestJS - A progressive Node.js framework