Dinamik modüller ve forRoot/forFeature deseni nedir?

Question

Accepted Answer

**Dinamik modüller**, içe aktarıldığında **yapılandırılabilen modüllerdir** — statik `@Module({...})` yerine, statik yöntemler (geleneksel olarak **`forRoot`** ve **`forFeature`**) sunarak, geçtiğiniz argümanlarla yapılandırılmış bir modül döndürür. Bu, yapılandırılabilir, yeniden kullanılabilir modüllerin (config, veritabanı, JWT) seçenekleri nasıl kabul ettiğidir.

## Çözdüğü sorun

```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.
```

## Zaten kullandığınız

```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 {}
```

Modülleri içe aktarırken gördüğünüz `.forRoot()`/`.register()`/`.forFeature()` çağrıları, yapılandırma kabul eden dinamik modül yöntemleridir.

## forRoot vs forFeature kuralı

```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)
```

Kural: global/tek seferlik yapılandırma için `forRoot`; birden fazla modülde çağırdığınız özellik başına kayıt için `forFeature`.

## Kendi dinamik modülünüzü oluşturma

```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" })
```

Statik yöntem, bir `DynamicModule` nesnesi (modül + providers + exports) döndürerek, geçilen seçenekleri modülün providers'ına (genellikle bir injection token üzerinden) bağlar.

## Asenkron yapılandırma (forRootAsync)

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

`forRootAsync` varyantı, yapılandırmanın diğer providers'a (örneğin `ConfigService`) bağlı olmasını sağlar — seçenekler doğrulanmış yapılandırmadan geldiğinde gereklidir.

## Neden önemli

Dinamik modüller ve `forRoot`/`forFeature` deseni, **yapılandırılabilir, yeniden kullanılabilir modüller** oluşturmak için önemli bir NestJS konseptidir — ve bunları anlamak, hem ekosistemi *kullanmak* hem de paylaşılan modüller *oluşturmak* için değerlidir.

Neredeyse her büyük NestJS modülü (ConfigModule, TypeOrmModule, JwtModule, BullModule, CacheModule) `.forRoot()`/`.register()`/`.forFeature()` ile yapılandırılan dinamik bir modüldür, bu nedenle bu çağrıların ne olduğunu (statik bir içe aktarma yerine, modüle yapılandırma iletme) tanımak tüm ekosistem nasıl bağlandığını aydınlatır.

**forRoot vs forFeature kuralı** (veritabanı bağlantısı veya gizli gibi tek seferlik global kurulum için forRoot; her modülde varlık kaydı gibi özellik başına kayıt için forFeature), sürekli karşılaştığınız bir örüntüdür.

Kıdemli geliştiriciler için, **kendi dinamik modüllerini oluşturmayı** bilmek (geçilen seçeneklerden yapılandırılmış providers'lı bir `DynamicModule` döndürme, genellikle injection tokenler aracılığıyla, yapılandırmaya bağımlı kurulum için asenkron varyantlarla) — reusable, yapılandırılabilir modüller oluşturmak için gereken şeydir — paylaşılan altyapı (depolama, dış API istemcileri, özel config) başka bir uygulamanın parçası veya başka projeler kendi ayarlarıyla içe aktarır.

Bu daha ileri bir konudur, ancak NestJS'in modüler mimarisini derinlemesine anlamak ve profesyonel, yeniden kullanılabilir modül kütüphaneleri oluşturmak için temeldir, bu da bunu büyük, iyi yapılandırılmış NestJS sistemlerini tasarlamak için önemli bir yetenek yapar.