Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Aetherall
Copy link

@Aetherall Aetherall commented Feb 10, 2022

PR Checklist

Please check if your PR fulfills the following requirements:

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
Copy link
Author

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

@kdawgwilk
Copy link
Contributor

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

@kdawgwilk
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

wodCZ commented Mar 6, 2023

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

@dontwan
Copy link

dontwan commented Sep 8, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants