GraphQL Federation
GraphQL Federation brings independent GraphQL services together into a single, unified API. It enables teams to develop, deploy, and scale their services independently while giving clients one coherent graph to query.
What is GraphQL Federation?
GraphQL Federation is an architectural approach that combines multiple independent GraphQL services, called subgraphs, into a single unified GraphQL API. Each subgraph contributes part of the overall schema, while a GraphQL gateway provides a single entry point for clients.
Instead of maintaining one large GraphQL server, teams can own and develop their services independently. Each team defines the types and fields its service provides, and a process called schema composition brings these definitions together into one coherent graph.
When a client sends a query, the gateway determines which subgraphs are needed, fetches the requested data, and assembles the results into a single response. To the client, the entire system behaves like one GraphQL API, regardless of how many services are involved.
What problem does GraphQL Federation solve?
One schema, one release process
Many GraphQL APIs start with a single server and a single schema. This approach is simple to develop, deploy, and maintain, especially when one team owns the entire API.
As an organization grows, multiple teams may need to contribute to the same graph. With a shared server and deployment process, changes often require coordination across teams. Releases become more complex, and teams can find themselves waiting on one another.
With GraphQL Federation
GraphQL Federation removes the need for every team to contribute to the same server. Instead, each team can own a subgraph with its own schema, implementation, and deployment lifecycle.
Schema composition combines these independently maintained schemas into one composite schema. It also detects conflicts and incompatible changes before a new composition is deployed, helping protect the integrity of the overall API.
Teams can evolve their services independently while clients continue to interact with one unified GraphQL API.
How does GraphQL Federation work?
Subgraphs
Independent GraphQL services that contribute types and fields to the overall graph.
Schema composition
Combines source schemas, establishes relationships, and validates their compatibility.
Distributed query execution
A GraphQL gateway executes a client query across the necessary subgraphs and assembles one response.
From Apollo Federation to GraphQL Federation
Apollo introduced federation in 2019, establishing the foundation for building distributed GraphQL APIs. GraphQL Federation takes these ideas forward as an open, vendor-neutral specification developed under the GraphQL Foundation, with contributions from Apollo, ChilliCream, IBM, Netflix, The Guild, WunderGraph, and the broader GraphQL community.
The new specification builds on Apollo Federation and GraphQL Fusion while establishing a common standard for schema composition and distributed query execution. It enables different GraphQL servers, gateways, and tools to work together without depending on a single vendor's technology.
Existing Apollo Federation subgraphs can continue to work without modification. Implementations such as Fusion support both approaches, allowing organizations to adopt GraphQL Federation incrementally, combine existing Apollo Federation subgraphs with new ones, and evolve their architecture at their own pace.
GraphQL Federation for AI-driven development
As AI coding agents become part of everyday software development, clear architectural boundaries matter more than ever.
Domain-Driven Design (DDD) has long helped teams manage complexity by organizing software around well-defined business domains. GraphQL Federation builds naturally on these principles, allowing each subgraph to represent a distinct domain with explicit ownership and a strongly typed API contract.
These boundaries are particularly valuable when working with AI agents. Instead of navigating an entire application, an agent can focus on a specific subgraph, understand its responsibilities, and make changes within a well-defined context. The GraphQL schema provides a clear contract, while schema composition helps detect incompatible changes before they reach production.
This makes GraphQL Federation a compelling architecture for large applications built by both developers and AI agents. Teams and agents can work independently within their domains while contributing to one coherent API.
How GraphQL Federation compares
GraphQL Federation is particularly well suited to large APIs with multiple independently developed services. Other approaches may be simpler depending on your architecture and requirements.
GraphQL Federation vs. a single GraphQL server
A single GraphQL server is often the simplest choice for smaller applications. Federation becomes valuable as APIs grow and teams need independent ownership, development, and deployment.
GraphQL Federation vs. Schema Stitching
Both approaches combine multiple GraphQL schemas into one API. Federation emphasizes explicit ownership and relationships defined by subgraphs, making it a natural fit for independently evolving services.
GraphQL Federation vs. Backend for Frontend (BFF)
BFFs create APIs tailored to individual applications, while federation provides a shared graph across backend services. The two approaches can complement each other.
GraphQL Federation vs. individual APIs
Calling each service's API directly is often simplest when clients need only a few services. Federation brings those APIs together into one unified GraphQL API, so clients no longer coordinate data across services themselves.
Get started with GraphQL Federation
Getting started with GraphQL Federation doesn't require rebuilding your existing APIs. With Fusion, you can bring together GraphQL, REST, and gRPC services into one unified graph.
Fusion supports both Apollo Federation and the GraphQL Federation specification, allowing you to use existing subgraphs without modification and adopt the open standard at your own pace.
Start with a single subgraph, connect additional services as your architecture grows, and let Fusion handle schema composition and distributed query execution.