GraphQL Federation is an approach to building a single GraphQL API out of many separately owned and deployed GraphQL services. A monolithic GraphQL schema works well at small scale, but as organizations grow, having every team contribute to one server becomes a bottleneck. Federation lets each team own a slice of the overall graph as an independent service, called a subgraph, while clients still see and query one cohesive schema, called the supergraph. This aligns the API’s structure with a microservices organization without exposing that fragmentation to consumers.
The pattern was pioneered by Apollo, whose Apollo Federation specification and tooling defined how subgraphs declare their types and how those types are combined. The Apollo documentation describes federation as a way to “declaratively combine multiple APIs into a single federated GraphQL API,” acting as “an API orchestration layer, where clients make a single GraphQL request and it coordinates multiple API calls to return a unified response.” Each subgraph publishes its own schema, and a composition step merges them into the supergraph that the gateway or router serves.
Central to federation is the ability for one subgraph to extend types defined by another. A products subgraph might own the Product type, while a reviews subgraph adds a reviews field to that same Product. Special directives mark entities and their key fields so the composition layer knows how to stitch the pieces together. At query time, a router resolves a client’s request by splitting it into the necessary calls across subgraphs, following entity references to gather data, and assembling a single response, preserving GraphQL’s promise of fetching exactly the needed data in one round trip.
The graphql.org learning material frames federation as a way for many teams to compose subgraphs into a supergraph, with a gateway sitting between clients and services and a schema composition process that merges schemas and resolves references between them. While Apollo’s implementation is the most widely deployed, the broader GraphQL community has worked toward open, vendor-neutral approaches to composite schemas, reflecting how influential the federation idea became.
Federation matters because it solved a real organizational scaling problem for GraphQL at large companies. Adopters including Netflix, Expedia, Volvo, and Booking used federation to let independent teams ship their own subgraphs while presenting customers and front-end developers with one unified graph. In doing so, federation extended GraphQL from a single-server query language into an architecture for distributed, multi-team API platforms.