Dynamic modules اور forRoot/forFeature pattern کیا ہیں؟

Question

Accepted Answer

**Dynamic modules** وہ modules ہیں جو **import کرتے وقت configured** ہو سکتے ہیں — ایک static `@Module({...})` کی بجائے، یہ static methods expose کرتے ہیں (روایتی طور پر **`forRoot`** اور **`forFeature`**) جو آپ کے پاس سے arguments لے کر ایک configured module واپس کرتے ہیں۔ یہی طریقہ ہے جس سے configurable، reusable modules (config، database، JWT) options قبول کرتے ہیں۔

## مسئلہ جو وہ حل کرتے ہیں

```text
A static module is fixed — but reusable modules (DatabaseModule, ConfigModule,
JwtModule) need to be CONFIGURED per app (connection URL, secret, options).
Dynamic modules let a module accept configuration at import time.
```

## آپ نے ان کو پہلے سے استعمال کیا ہے

```ts
@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),               // ← forRoot with options
    TypeOrmModule.forRoot({ type: "postgres", url: ... }),  // ← configured at import
    JwtModule.register({ secret: process.env.SECRET }),      // ← register variant
    TypeOrmModule.forFeature([User, Post]),                  // ← forFeature for specifics
  ],
})
export class AppModule {}
```

آپ جو `.forRoot()`/`.register()`/`.forFeature()` calls دیکھتے ہیں جب modules import کرتے ہیں وہ dynamic-module methods ہیں جو configuration قبول کرتے ہیں۔

## forRoot بمقابلہ forFeature convention

```text
forRoot()    → configure the module ONCE, globally (the connection, the secret, core setup)
               called in the root/app module a single time
forFeature() → register feature-specific pieces in each feature module that needs them
               (e.g. TypeOrmModule.forFeature([User]) registers entities per module)
```

Convention یہ ہے: `forRoot` global/one-time configuration کے لیے; `forFeature` per-feature registration کے لیے جو آپ متعدد modules میں call کرتے ہیں۔

## اپنا dynamic module بنانا

```ts
@Module({})
export class StorageModule {
  static forRoot(options: StorageOptions): DynamicModule {
    return {                                  // returns a configured module
      module: StorageModule,
      providers: [
        { provide: "STORAGE_OPTIONS", useValue: options },   // inject the passed options
        StorageService,
      ],
      exports: [StorageService],
      global: true,                            // optionally make it global
    };
  }
}
// usage: StorageModule.forRoot({ bucket: "my-bucket", region: "us-east-1" })
```

Static method ایک `DynamicModule` object واپس کرتا ہے (module + providers + exports)، جو pass کیے گئے options کو module کے providers میں wire کرتا ہے (اکثر ایک injection token کے ذریعے)۔

## Async configuration (forRootAsync)

```ts
// configure using OTHER injected dependencies (e.g. ConfigService) — async/factory
StorageModule.forRootAsync({
  useFactory: (config: ConfigService) => ({ bucket: config.get("BUCKET") }),
  inject: [ConfigService],
});
```

`forRootAsync` variant configuration کو دوسری providers (جیسے `ConfigService`) پر منحصر کرنے دیتا ہے — ضروری ہے جب options validated configuration سے آتے ہیں۔

## یہ کیوں اہم ہے

Dynamic modules اور `forRoot`/`forFeature` pattern ایک اہم NestJS concept ہے **configurable، reusable modules** بنانے کے لیے — اور ان کو سمجھنا قیمتی ہے دونوں *ecosystem استعمال کرنے* اور *shared modules بنانے* کے لیے۔

تقریباً ہر بڑا NestJS module (ConfigModule، TypeOrmModule، JwtModule، BullModule، CacheModule) ایک dynamic module ہے جو `.forRoot()`/`.register()`/`.forFeature()` کے ذریعے configured ہے، تو یہ سمجھنا کہ یہ calls کیا کرتے ہیں (module کو import کرتے وقت configuration pass کرنا، بجائے ایک static import) یہ واضح کرتا ہے کہ پوری ecosystem کیسے wired ہے۔

**forRoot بمقابلہ forFeature convention** (forRoot one-time global setup کے لیے جیسے database connection یا secret; forFeature per-feature registration کے لیے جیسے ہر module میں entities register کرنا) یہ ایک pattern ہے جو آپ مسلسل سامنا کرتے ہیں۔

Senior developers کے لیے، یہ جاننا کہ **اپنے اپنے dynamic modules کیسے بنائیں** (ایک `DynamicModule` واپس کریں جس میں providers passed options سے configured ہوں، اکثر injection tokens کے ذریعے، async variants کے ساتھ config-dependent setup کے لیے) یہ ہے جو آپ کو reusable، configurable modules بنانے دیتا ہے — shared infrastructure (storage، external API clients، custom config) جو app کے دوسرے حصے یا دوسری projects اپنی اپنی settings کے ساتھ import کریں۔

یہ ایک زیادہ advanced topic ہے، لیکن یہ NestJS کے modular architecture کو گہرائی سے سمجھنے کے لیے بنیادی ہے اور professional، reusable module libraries بنانے کے لیے، اسے large، well-structured NestJS systems کو architect کرنے کے لیے ایک اہم صلاحیت بناتے ہوئے۔