Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

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

Open
Aetherall wants to merge 2 commits into nestjs:master
base: master
Choose a base branch
Loading
from Aetherall:multigraph

Conversation

@Aetherall
Copy link

@Aetherall Aetherall commented Feb 10, 2022
edited
Loading

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 !

benjah13, LucM, timurrustamov, OdileGuillaume, sebastiendelecraz, dedicad, nilscox, rvitaliy, dolivier83, miramo, and 11 more reacted with thumbs up emoji LucM and andrewmclagan reacted with hooray emoji kdawgwilk, cvramirez-nasa, AhmedElBanna80, and andrewmclagan reacted with heart emoji LucM and andrewmclagan reacted with rocket emoji
Copy link
Author

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

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

Aetherall and grinono reacted with thumbs up emoji

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?

appinteractive, b-bellovic, Aetherall, and grinono reacted with heart emoji

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 !

Copy link
Contributor

wodCZ commented Mar 6, 2023

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

Copy link

dontwan commented Sep 8, 2023

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

appinteractive, alex-deity, igorgolovanov, and andrewmclagan reacted with thumbs up emoji

Copy link

ghost commented Mar 5, 2025
edited by ghost
Loading

can we have multiple endpoints?

it is not workkkkkkkk
//documents:
Multiple endpoints#
Another useful feature of the @nestjs/graphql module is the ability to serve multiple endpoints at once. This lets you decide which modules should be included in which endpoint. By default, GraphQL searches for resolvers throughout the whole app. To limit this scan to only a subset of modules, use the include property.

GraphQLModule.forRoot({
include: [CatsModule],
}),
@kamilmysliwiec

Copy link

ghost commented Mar 15, 2025

Any progress on this PR? I want to use multiple endpoints
@kamilmysliwiec

Copy link

ghost commented Mar 21, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /