Allow for multiple graphql endpoints in the same application with schema segregation

[Aetherall]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

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
• CI related changes
• Other... Please describe:

Why this feature ?

In some approaches of application development, we want to split our code into bounded contexts.
GraphQL's federation allows us to defer the aggregation of data needed for cross-contexts read use-cases.
However, deployment of applications should be decoupled from their internal context dependency scheme,
as it allows flexibility throughout the discovery of the infrastructure requirements of each context.

What is the current behavior?

Currently, having 2 GraphQLModule in the same application will result in the application not wanting to start, yielding the following error :

Schema must contain uniquely named types but contains multiple types named "User".

This is due to the fact that we add GraphQL types/interface/etc. to the schema globally.
Cf: orphaned-types.factory.ts

This have the effect to generate schemas containing definitions for both contexts,
thus creating a conflict beween original ObjectTypes and their extended counterparts named the same.

What is the new behavior?

The new behavior would allow for a nest user to have multiple GraphQL endpoints in a single nest application.
Those endpoints would expose a schema only containing definitions referenced by the resolvers below the included modules.
An example application, along with corresponding tests, can be found in the apollo package of the repository.

Does this PR introduce a breaking change?

• Yes
• No
• Not known yet

Other information

I am asking for insights on how I should approach the problem.
The newly written tests are passing when entirely disabling the orphaned type retrieval ^^'
It could be useful to me to understand the origin for global orphaned type registration, and if there is a way to access them from the resolvers used to create the schema.

Thanks a lot !

[Aetherall]

I am wondering if the approach of exploring resolver metadata to reference the types will cover all use cases

[kdawgwilk]

This is exactly the use case I was trying to attempt in #2164 however with schema first approach instead of code first

[kdawgwilk]

It was mentioned in this PR #1432 (comment)

introduce a new feature that lets you associate types (e.g., object types) with NestJS modules, for example, using the following construction @ObjectType({ registerIn: CatsModule }). In this case, types wouldn't be global anymore and we could store them per app instead of a per process

Maybe that would be a direction to start in that would be supported by the maintainers?

[Aetherall]

Thanks for the heads up @kdawgwilk, I was using my dirty fix since then and forgot about the issue.

I will try to implement something as soon as I get back from holidays.

Don't hesitate to use my PR as an iteration base if you want to try something until then !

[wodCZ]

I believe this is related to #721. Linking this for reference.

[dontwan]

Any progress on this PR?
I will also like to use multiple endpoints