The Explaination of forRoot and ForFeature

forRootAndForFeature.md

ForRoot

This is useful when the registerAs is required across, so it is best to use it in the AppModule

import databaseConfig from './config/database.config';
@Module({
  imports: [
    ConfigModule.forRoot({
      load: [databaseConfig],
    }),
  ],
})
export class AppModule {}

the registerAs has to be loaded into the configureModule.forRoot by adding it in the the load array.

ForFeature

This is valuable to ensure the registerAs is only applicable for the module only. It is better as most of the config is required for the respective modules only.

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import databaseConfig from './database.config';

@Module({
  imports: [ConfigModule.forFeature(databaseConfig)],
  providers: [],
  exports: []
})
export class CouchdbModule { }

if I have understood correctly

below every number represents a module

        0                                                                                                
    1       2                                                                                            
  3   4   5   6                                                                                          

if I do forRoot(databaseConfig) on module 1 then 1, 3, 4 can use databaseConfig
if I do forFeature(databaseConfig) on module 1 then only 1 can use the databaseConfig
if I do forRoot(databaseConfig) on module 0 then all can use the databaseConfig

very clear explanation, would recommend this guy putting his course online

very clear explanation

    0                                                                                                
1       2                                                                                            

3 4 5 6
if I do forRoot(databaseConfig) on module 1 then 1, 3, 4 can use databaseConfig
if I do forFeature(databaseConfig) on module 1 then only 1 can use the databaseConfig
if I do forRoot(databaseConfig) on module 0 then all can use the databaseConfig

so may I ask, is it correct explanation?

What about validating the configuration in forFeature? I know that in forRoot we have something like:

ConfigModule.forRoot({
    validationSchema: Joi.object({....}),
    load: [databaseConfig]
})

If I understand correctly, forRoot and forFeature are just convention. Because the instantiation is actually checks for the token which is based on the passed parameter (dbconfig in the sample). So if we use forRoot in two different modules with the same setting, we will still have 1 instance, the second forRoot call will receive the first instance. And if in a module we have 2 calls forRoot with different dbConfig, we will have 2 instances.

And forFeature on the other hand is intended to be using existing instance with additional option.

very clear explanation

@alim7007

very nice

The best explanation, really yes!