-
Notifications
You must be signed in to change notification settings - Fork 42
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
Feature Request: Support Apollo Federation #42
Comments
this sounds very cool @StevenACoffman thanks for bringing it to our attention. i would add this to a list of items we'd want to support when we upgrade the version of gqlgen sqoop is built on is federation a suitable substitute for schema stitching? stitching is something we were looking at as well for sqoop |
There’s a pretty good write up as to why Apollo is deprecating schema stitching in favor of Federation.
|
Hi! So, there have been a small number of releases of github.com/99designs/gqlgen and https://github.com/vektah/gqlparser since the Apollo Federation support landed in them. Upgrading to the latest would instantly allow sqoop to be used as a component of an Apollo Federation behind Apollo Server's federated gateway implementation. |
Feature Request:
Please consider supporting Graphql Federation. There is some work ongoing to add federation support for gqlgen.
Apollo Federation is made up of two parts:
To be part of a federated graph, a microservice implements the Apollo Federation spec which exposes its capabilities to tooling and the gateway. The federated service can extend types from other services and add its own types that can be extended.
Collectively, federated services form a composed graph. This composition is done by a gateway which knows how to take an incoming operation and turn it into a plan of fetches to downstream services. The gateway orchestrates requests, merges the data and errors together, and forms the overall result to send back to the client.
Background:
We use hundreds of microservices, and a monolithic GraphQL server becomes an unacceptable development bottleneck and single point of failure, so it becomes necessary to divide the graph's implemention into separate parts. We tried schema stitching, but would prefer federation for three reasons:
The text was updated successfully, but these errors were encountered: