Feature Request: Support Apollo Federation

[StevenACoffman]

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:

• Federated services, which are standalone parts of the graph
• A gateway which composes the overall schema and executes federated queries

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:

1. With federation, microservices all expose a proper part of the overall graph and can refer directly to types that live in other services, without the need to add foreign keys or superfluous relationship root fields to your schema.
2. Federation is fully declarative and doesn't require any user code to be running in the gateway.
3. Execution is efficient and predictable, because it relies on a query plan generated ahead of time with full knowledge of the overall query, instead of on runtime schema delegation that gets invoked as part of normal resolver-based execution.

[ilackarms]

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

[StevenACoffman]

There’s a pretty good write up as to why Apollo is deprecating schema stitching in favor of Federation.

1. With federation, microservices all expose a proper part of the overall graph and can refer directly to types that live in other services, without the need to add foreign keys or superfluous relationship root fields to your schema.
2. Federation is fully declarative and doesn't require any user code to be running in the gateway.
3. Execution is efficient and predictable, because it relies on a query plan generated ahead of time with full knowledge of the overall query, instead of on runtime schema delegation that gets invoked as part of normal resolver-based execution.

[StevenACoffman]

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.