The Future of GraphQL Federation - WunderGraph

State of GraphQL Federation 2026

Curtis Layne
July 16, 2025 · 12min read
Edited on July 5, 2026 by Brendan Bondurant

Apollo introduced GraphQL Federation v1.0 in May 2019. Since then, there’s been one major iteration to v2.0 released in April 2022.

Apollo Federation solves a real need, but it still has many significant shortcomings, even 6 years after it was introduced.

In this post, we’ll explore the good, the bad, and where the ecosystem is going to build a better future for GraphQL Federation.

TL;DR

Apollo Federation solved a real need, but six years on it still leaks query planning and entity lookup details out of the Router and into the subgraphs, which means every one of the 75+ GraphQL server implementations has to carry custom, non-spec code, and each new primitive demands more. It also pays a performance cost by sending GraphQL over HTTP and JSON between Router and subgraphs, and forces subgraphs to be more complex than they need to be. The ideal is the opposite: clients see one unified supergraph, the Router holds the complexity, subgraphs run in any language, and batching is built in. The Composite Schema spec fixes some of this, but its @require fields cannot be batched, so it steps backward on performance. Generating Proto and gRPC subgraphs, the path Cosmo is taking, auto-generates batch entity lookups to solve N+1, runs natively in every major language, and lets new Federation primitives ship as new endpoint contracts, which from first principles can solve all four goals.

🤔 Why Federation?

Client engineers love using GraphQL. Being able to see all of your data as a single, queryable entity, and not having to rebuild entity joining logic on every client (web + Android + iOS + tvOS + etc), is incredibly powerful, and enables teams to move much more quickly.

But GraphQL is just a schema and query specification — it offers zero guidance on managing complexity as your schema grows from dozens to thousands of types. As schemas and GraphQL deployments grow, companies start running into the same set of organizational problems that lead them to adopt microservices.

Apollo had a great insight: with Federation, rather than building a giant, monolithic GraphQL server, companies can split the GraphQL schema into “subgraphs”. This enables us to get the best of all worlds:

✅ Good parts

Apollo Federation gets a lot right:

🔑 Declarative Relationships with @key

The core of the Apollo Federation spec revolves around the concept of foreign key constraints (@key in the Federation specification) and a query planner — not unlike a database engine.

Relationships between subgraph microservices can be made declaratively with the Federation Router, the equivalent of the database engine, planning queries, executing them, and assembling the responses. This works very well to enable entity definitions, such as type User, to be split across multiple microservices.

🖥️ Computed properties

There are other cool ideas in the spec as well, like @requires, which enables subgraphs to contribute derived fields to existing entities.

🚨 Problems

When you dig in more deeply, it becomes clear that there are serious design and scaling concerns.

🌊 Apollo Federation leaks into the subgraphs

The first and largest issue is that the Apollo Federation spec leaks implementation details about how query planner works out of the Router and into the subgraphs. The Router is aware of this concept as it has to plan, execute, and then assemble the response using these rules.

🧩 75+ GraphQL server implementations

This complex work gets pushed down into every single GraphQL server to implement custom, non-GraphQL spec code in the server itself to be compatible with Federation.

🐢 Performance bottlenecks

Another issue is subgraph performance. Queries that come into the Router must then be broken down into smaller queries and sent to the subgraph servers over HTTP+JSON using standard GraphQL requests. For companies with a high load on their servers, this is a meaningful performance hit.

👩🏻‍🔬 Subgraphs are overengineered

GraphQL is inherently fairly complex to implement in the server, requiring an advanced orchestration engine. With Federation, however, the subgraphs don’t actually need to carry this complexity and can be simpler API servers.

😕 @requires is a headache

While @requires seems powerful, it has limitations: you can’t @requires fields from your own subgraph, and there are complexities with handling errors from upstream fields.

💡 What can we do instead?

Ideal Federation specification properties

  1. Clients see only a unified supergraph schema.
  2. Push complexity into the Router.
  3. Subgraph servers can be implemented in any language.
  4. High performance subgraph servers out of the box.

Options to improve Federation

  1. Composite Schema specification: A new version of subgraph Federation is being worked on that aims to rectify current issues.
  2. Proto+gRPC subgraphs: An approach that auto-generates batch entity lookup endpoints and is designed to solve N+1 problems, potentially leading to better performance and simplified implementations.

🏁 Final thoughts

GraphQL Federation is an incredibly powerful concept, but the right model for scaling inside large enterprises hasn't been nailed down yet.

Frequently Asked Questions (FAQ)

What does Apollo Federation get right?
Apollo Federation splits a monolithic GraphQL schema into subgraphs, allowing teams to deploy independently.

What is the core problem with Apollo Federation architecture?
It leaks implementation details about query planning into the subgraphs.

Why are 75+ GraphQL server implementations a scaling problem for Federation?
Each new Federation primitive requires custom code changes across all implementations.

Why does Apollo Federation create a performance bottleneck?
Queries are sent over HTTP and JSON, causing performance issues under high load.

What are the problems with the @requires directive?
Constraints on its flexibility limit its effectiveness.