docs(): durable providers feature

[kamilmysliwiec]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/docs.nestjs.com/blob/master/CONTRIBUTING.md

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Docs
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[kamilmysliwiec]

@jmcdo29 if you can check grammar etc that would be super helpful 🙌
If you had some time to review these PRs:

• feat: add docs for repl v9 feature #2361
• docs(file-upload): add file validators section #2360
• docs(): add configurable module builder instructions #2357
• docs(): update migration guide, list breaking changes #2363
  that would be wonderful 💪

[Tony133]

I think it is well written 👍 . I have only added two small fixes

[Tony133]

Suggested change

For instance, let's say you have an application alternately used by 10 different customers. Each customer has its **own dedicated data source**, and you want to make sure customer A will never be able to reach customer's B database. For this, you could declare a request-scoped "data source" provider that - based on the request object - determines what's the "current customer" and retrieves its corresponding database. With this approach, you can turn your application into a multi-tenant application in just a few minutes. The major downside is - since most likely a large chunk of your application' components rely on the "data source" provider, they will implicitly become "request-scoped", and therefore certainly impacting your app performance.

For instance, let's say you have an application alternately used by 10 different customers. Each customer has its **own dedicated data source**, and you want to make sure customer A will never be able to reach customer's B database. For this, you could declare a request-scoped "data source" provider that - based on the request object - determines what's the "current customer" and retrieves its corresponding database. With this approach, you can turn your application into a multi-tenant application in just a few minutes. The major downside is - since most likely a large chunk of your application components rely on the "data source" provider, they will implicitly become "request-scoped", and therefore certainly impacting your app performance.

[jmcdo29]

This is a sweet new feature! Great to see something like this! Grammar in it looks good too