In a federated architecture, each microservice (subgraph) owns part of the schema — e.g., UserService owns User types, OrderService owns Order types. The router composes these into a unified supergraph for clients.
2 / 5
The router (or gateway) in a federated GraphQL setup:
The router is the single entry point for clients. It receives a query, uses the composed supergraph to plan which subgraphs to call (and in what order), executes the query plan, and assembles the final response.
3 / 5
The @key directive in Apollo Federation marks:
The @key directive tells Federation that this type can be uniquely identified by the specified field(s). Other subgraphs can extend the type and the router can use the key to fetch the entity from the owning subgraph.
4 / 5
Schema composition in GraphQL Federation means:
Composition takes all subgraph schemas, validates that cross-schema references are consistent (e.g., @key fields match, @external fields exist), and produces the supergraph schema that the router uses for query planning.
5 / 5
What is the main advantage of GraphQL Federation over schema stitching?
Schema stitching required a central gateway team to stitch schemas and handle cross-service resolution manually. Federation pushes ownership to subgraph teams — each team declares their schema and the composition is handled automatically.