Merge pull request #2221 from jmcdo29/feat/root-register-feature

feat: mention the different registration methods

Author: kamilmysliwiec

content/fundamentals/dynamic-modules.md

@@ -261,6 +261,21 @@ One final note: for simplicity we used a string-based injection token (`'CONFIG_
 export const CONFIG_OPTIONS = 'CONFIG_OPTIONS';
 ```
 
+### Community Guidelines
+
+You may have seen the use for methods like `forRoot`, `register`, and `forFeature` around some of the `@nestjs/` packages and may be wondering what the difference for all of these methods are. There is no hard rule about this, but the `@nestjs/` packages try to follow these guidelines:
+
+When creating a module with:
+
+* `register`, you are expecting to configure a dynamic module with a specific configuration for use only by the calling module . For example, with Nest's `@nestjs/axios`: `HttpModule.register({{ '{' }} baseUrl: 'someUrl' {{ '}' }})`. If, in another module you use `HttpModule.register({{ '{' }} baseUrl: 'somewhere else' {{ '}' }})`, it will have the different configuration. You can do this for as many modules as you want.
+
+* `forRoot`, you are expecting to configure a dynamic module once and reuse that configuration in multiple places (though possibly unknowingly as it's abstracted away). This is why you have one `GraphQLModule.forRoot()`, one `TypeOrmModule.forRoot()`, etc. 
+
+* `forFeature`, you are expecting to use the configuration of a dynamic module's `forRoot` but need to modify some configuration specific to the calling module's needs (i.e. which repository this module should have access to, or the context that a logger should use.)
+
+
+All of these, usually, have their `async` counterparts as well, `registerAsync`, `forRootAsync`, and `forFeatureAsync`, that mean the same thing, but use Nest's Dependency Injection for the configuration as well.
+
 ### Example
 
 A full example of the code in this chapter can be found [here](https://github.com/nestjs/nest/tree/master/sample/25-dynamic-modules).