Dynamic module và pattern forRoot/forFeature là gì?

Question

IT Interview Practice · Accepted Answer

**Dynamic module** là các module có thể được **cấu hình khi import** — thay vì một `@Module({...})` tĩnh, chúng phơi bày các static method (theo quy ước là **`forRoot`** và **`forFeature`**) trả về một module được cấu hình với các argument bạn truyền vào. Đây là cách các module có thể cấu hình, tái sử dụng (config, database, JWT) nhận các tùy chọn.

## Vấn đề chúng giải quyết

```text
Một module tĩnh là cố định — nhưng các module tái sử dụng (DatabaseModule, ConfigModule,
JwtModule) cần được CẤU HÌNH theo từng ứng dụng (URL kết nối, secret, các tùy chọn).
Dynamic module cho phép một module nhận cấu hình lúc import.
```

## Bạn đã dùng chúng rồi

```ts
@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),               // ← forRoot với các tùy chọn
    TypeOrmModule.forRoot({ type: "postgres", url: ... }),  // ← cấu hình lúc import
    JwtModule.register({ secret: process.env.SECRET }),      // ← biến thể register
    TypeOrmModule.forFeature([User, Post]),                  // ← forFeature cho cái cụ thể
  ],
})
export class AppModule {}
```

Các lời gọi `.forRoot()`/`.register()`/`.forFeature()` bạn thấy khi import module là các method dynamic-module nhận cấu hình.

## Quy ước forRoot vs forFeature

```text
forRoot()    → cấu hình module MỘT LẦN, toàn cục (kết nối, secret, thiết lập cốt lõi)
               gọi trong root/app module một lần duy nhất
forFeature() → đăng ký các phần đặc thù tính năng trong mỗi feature module cần chúng
               (vd. TypeOrmModule.forFeature([User]) đăng ký entity theo từng module)
```

Quy ước: `forRoot` cho cấu hình toàn cục/một lần; `forFeature` cho đăng ký theo tính năng mà bạn gọi trong nhiều module.

## Xây dynamic module của riêng bạn

```ts
@Module({})
export class StorageModule {
  static forRoot(options: StorageOptions): DynamicModule {
    return {                                  // trả về một module được cấu hình
      module: StorageModule,
      providers: [
        { provide: "STORAGE_OPTIONS", useValue: options },   // inject các tùy chọn truyền vào
        StorageService,
      ],
      exports: [StorageService],
      global: true,                            // tùy chọn làm cho nó toàn cục
    };
  }
}
// cách dùng: StorageModule.forRoot({ bucket: "my-bucket", region: "us-east-1" })
```

Static method trả về một object `DynamicModule` (module + provider + exports), kết nối các tùy chọn truyền vào các provider của module (thường qua một injection token).

## Cấu hình async (forRootAsync)

```ts
// cấu hình dùng các dependency được inject KHÁC (vd. ConfigService) — async/factory
StorageModule.forRootAsync({
  useFactory: (config: ConfigService) => ({ bucket: config.get("BUCKET") }),
  inject: [ConfigService],
});
```

Biến thể `forRootAsync` cho phép cấu hình phụ thuộc vào các provider khác (như `ConfigService`) — thiết yếu khi các tùy chọn đến từ cấu hình đã được validate.

## Tại sao điều này quan trọng

Dynamic module và pattern `forRoot`/`forFeature` là một khái niệm quan trọng của NestJS để xây dựng các **module có thể cấu hình, tái sử dụng** — và hiểu chúng là giá trị cả cho việc *dùng* hệ sinh thái và *xây dựng* các module dùng chung.

Gần như mọi module NestJS lớn (ConfigModule, TypeOrmModule, JwtModule, BullModule, CacheModule) là một dynamic module được cấu hình qua `.forRoot()`/`.register()`/`.forFeature()`, nên nhận biết các lời gọi này là gì (truyền cấu hình tới một module lúc import, thay vì một import tĩnh) làm sáng tỏ cách cả hệ sinh thái được kết nối.

Quy ước **forRoot vs forFeature** (forRoot cho thiết lập toàn cục một lần như một kết nối database hoặc secret; forFeature cho đăng ký theo tính năng như đăng ký entity trong mỗi module) là một pattern bạn gặp liên tục.

Với các lập trình viên senior, biết cách **xây dynamic module của riêng mình** (trả về một `DynamicModule` với các provider được cấu hình từ các tùy chọn truyền vào, thường qua injection token, với các biến thể async cho thiết lập phụ thuộc config) là điều cho phép bạn tạo các module tái sử dụng, có thể cấu hình — hạ tầng dùng chung (storage, client API bên ngoài, config tùy chỉnh) mà các phần khác của một ứng dụng hoặc các dự án khác import với các thiết lập riêng của chúng.

Đây là một chủ đề nâng cao hơn, nhưng nó là nền tảng để hiểu sâu kiến trúc module hóa của NestJS và để xây dựng các thư viện module chuyên nghiệp, tái sử dụng, khiến nó trở thành một khả năng quan trọng để kiến trúc các hệ thống NestJS lớn, có cấu trúc tốt.

Vấn đề chúng giải quyết

Bạn đã dùng chúng rồi

Quy ước forRoot vs forFeature

Xây dynamic module của riêng bạn

Cấu hình async (forRootAsync)

Tại sao điều này quan trọng

Câu hỏi liên quan