-
-
Notifications
You must be signed in to change notification settings - Fork 940
Distributed GraphQL #291
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
Comments
I don't think there is a good answer to this one yet. Some conversations from the JS community: GraphQL is pretty much designed around a single server architecture currently which makes this a bit harder. Here are a couple options I can think of:
|
apollo is implementing it now https://dev-blog.apollodata.com/graphql-schema-stitching-8af23354ac37 |
i'm exploring a bit on this topic. the schema builder in 2.0 is pretty cool for this. and it should be possible to implement the merging algorithm on top of this. the harder part is the type resolving. currently it looks like we need explicit types in the DI to be able to resolve additional types. There's no fallback to handle local unresolved types. Maybe we can introduce some kind of universal type which can route those unresolved types. @joemcbride do you have an idea how you would implement the resolver logic? |
@OneCyrus @joemcbride Are there any updates on this topic? I have the same question as @OneCyrus for @joemcbride as to what the best strategy would be for implementing distributed queries (at a high level)? |
@troydalldorf we started working on this in #592 though lately there's not much progress on our side. but this should change early next year as we want to push this forward. |
We also have a microservice architecture in alpha which uses GraphQL to provide a gateway. Our approach is similar to GraphQL Hub's.
For example, suppose I have two schemas:
The merged schema would look like:
Unfortunately I can't share the code which performs the merger because I don't own it. I can say it was not difficult to write. We like this plan so far because the boundaries of each microservice are clearly marked by the top-level fields in each root object, and it's easy to test each component schema separately. The client, however, is slightly disadvantaged because they have an extra level of nesting to drill through before getting to their query results. We've accepted this trade-off. If there are other disadvantages to this strategy we haven't advanced far enough to see them yet - both our microservices and their GraphQL schemas are simple, and their functions are distinct enough that we don't see value in trying to handcraft a schema that is aware of the overall system. |
Relates to #1233 |
See #592 (comment) I am going to close this issue due to lack of activity and the fact that it has been a long time since the original question. If the problem is still relevant, then it is worth creating a new issue and we will try to figure it out using modern approaches. |
Hello,
First of all, thanks for the library, it's a great piece of code.
I'm looking for an advice about making distributed GraphQL on top of this library.
I have a few microservices (A, B) and gateway. Web application sends requests only to the gateway (and doesn't know about other services).
I would like to make somehow schema partitioned between every microservice. So the gateway service won't define schema, just collects it from other services and provides to the client.
Visualized:
For now, ignore cross queries, like:
Where should I start? Implement custom
IDocumentExecuter
? Or is it better to integrate this library to every microservice and just resend request and merge responses?The text was updated successfully, but these errors were encountered: