State of Federation 2026

TL;DR

GraphQL started as a monolithic API model and grew through Schema Stitching into modern Federation. Along the way, enterprises discovered that distributing APIs across teams requires a unifying layer. That’s where the Entity Layer comes in: a foundation for modeling the domain as entities, enforcing graph integrity, and supporting collaborative schema design and governance to ensure consistency. This post traces that evolution and explains why the Entity Layer is now a key building block for unified APIs. For a practical comparison of how Apollo Federation, GraphQL Federation, and Cosmo Connect each implement the Entity Layer today, see Cosmo Connect vs Apollo Federation vs GraphQL Federation.

What is the Entity Layer?

The Entity Layer is the layer that models your whole domain as entities and the relationships between them, independent of any single backend or API style. It gives you one place to enforce graph integrity and to handle batching, caching, access control, and schema governance, instead of reimplementing those concerns in every service.

The Problem: Building a Unified API Layer

Across all the different approaches, it's clear there's agreement on some core principles:

1. A unified API Layer is needed (I'll explain why in a bit)
2. GraphQL is the ideal foundation (this will be covered in the next section)
3. Entities are the core building block to distribute a GraphQL Schema across multiple services

The reason we need a unified API Layer is simple. As your organization grows, you will continue to add more and more use cases, which are your API consumers. To meet all their requirements, your engineering team won't just add more APIs, but the team itself will also grow.

You’ll typically start with one or a small number of services implementing core business logic, and after some time, especially if you're a fast-growing, successful company, you'll quickly scale from 3 teams to 20 or even 100, and from 5 services to 50 or 300.

Now, there are two ways to approach this:

1. Build all APIs fully in isolation, put them in a catalog, and let API consumers pick and choose which APIs to use. This way, integration is decentralized and the burden is on the API consumer
2. Build a unified API Layer, where integration is centralized and the cost is paid upfront by the API producer

Why should enterprise API integration be centralized on the producer side?

The traditional way to build enterprise APIs is to split your domain across multiple services, expose these services through REST or gRPC, and then publish the API contract to an API developer portal. Protected by an API Gateway, consumers can explore all existing APIs through a catalog, and get access with an API key.

However, this approach has many drawbacks. There's usually little to no collaboration across teams, which means specifications across services are often inconsistent. I once worked with a car manufacturer that had 13 different definitions for the 'Car' entity. You might request a car from one service and assume that the unique identifier is the same across all services, but that simply wasn't the case. The lack of naming conventions and a shared understanding of the domain puts the API consumer in a very bad position.

If, on the other hand, we're building a unified API Layer, that is, a single GraphQL Schema across all services, the burden of understanding the domain and the API contract is no longer on the API consumer. It is now an upfront cost on the API producer side.

Why is GraphQL the optimal choice for a unified API layer?

If you have followed the narrative so far, you might agree that a unified API Layer is the way to go, but it's not yet clear why GraphQL is the optimal choice for the implementation.

GraphQL is a great fit for building a unified API Layer because of the SelectionSet concept. It allows API consumers to request only the data they need, which automatically limits the amount of information that will be requested by the underlying services.

— Jens Neuse

Without SelectionSets, we'd request an infinite amount of data on every path. We could implement similar functionality with a REST API, but that would essentially mean reinventing GraphQL on top of REST. With GraphQL, we have a very simple concept to model relationships between entities, and we can then use the SelectionSet concept to express which fields we'd like to request.

Benefits of Building a Unified API on GraphQL

• All service teams have a simple mechanism to agree on the definition of an entity
• If an entity is shared across multiple services, all involved teams have to agree on the unique identifier(s)
• The Router always makes the minimum number of fetches to the underlying services
• Nested entity requests are automatically batched
• From an API consumer perspective, the API contract is simple and easy to understand, it looks like a single monolithic GraphQL Schema
• The complexity of the underlying services is completely hidden from the API consumer
• API consumers can easily fetch relationships between entities without having to read through an endless list of REST endpoints
• New fields can be added to an entity without changing the API contract

Conclusion

GraphQL’s path from monoliths to Federation shows a simple truth: as domains and teams grow, you need a shared layer. The Entity Layer is introduced as a fundamental building block for unified APIs.

It brings scattered services together by defining entities, keys, and responsibilities, while its runtime handles batching, caching, and supports collaborative schema design and governance. That’s why Federation works in practice—and why the Entity Layer is now the foundation for unified APIs.