Innovate faster with
GraphQL federation

GraphQL federation is the missing API layer for distributed architectures. It removes friction between the backend and the frontend, enabling teams to deliver anything from chatbots to bug fixes with less coordination and boilerplate code.

Get started with GraphOS
Contact our team

Learn why enterprises choose GraphQL federation

Image hero

An API composition layer

Power any number of client apps with GraphQL federation.

Enterprises often have hundreds of microservices that serve any number of client applications. Writing backends-for-frontends (BFFs) to mitigate this complexity introduces inconsistencies, technical debt, and friction between teams that slows down innovation.

Rather than delivering services to frontend teams as a series of handwritten BFFs, service teams can deliver APIs as a self-service graph. This supergraph sits on top of existing services, so there is nothing to re-architect. It can be evolved to suit the needs of the business with fewer breaking changes downstream. And client teams can use a declarative query language to fetch all the data they need from a single endpoint.

Why choose GraphQL federation?

A self-service contract

GraphQL federation enables service teams to contribute to a self-documenting supergraph that any frontend team can query. Using GraphQL makes it easier to evolve APIs, causing less friction and fewer breaking changes.

A single semantic layer

Create an API access layer that defines business domains and the relationships between them. This provides better composability and drives a consistent user experience across your apps.

An enterprise-grade solution

A supergraph can power billions of operations a day across any number of applications. And because it fuels reuse, it’s easier and faster to deliver any number of applications in the future too.

How it works

Define domains in any language

GraphQL federation provides an ideal architecture for domain-driven design. Service teams can define domains as well as the relationships between them as a graph.

To do this, service developers contribute individual GraphQL APIs in any language to a supergraph. Since GraphQL doesn't require versions, it's easier to evolve these APIs over time.

Compose a supergraph

A process called composition combines these subgraph schemas into a unified schema.

While the supergraph is modular for service teams, it provides a single self-service platform for any number of client applications, present or future.

Provide a single endpoint

This architecture doesn't just provide composability and resilience for service teams. It radically simplifies the client developer experience too.

Client teams can fetch the data they need using a declarative query language and a single endpoint — no matter where that data is stored. They can focus less on API wrangling and more on the features that drive your business.

Get started with GraphQL federation today