GraphQL Federation: The Missing API for Your Platform Strategy
Platform engineering has emerged as a key discipline to unlock developer velocity in cloud native architectures. From the infrastructure provisioned and orchestrated with Terraform and Kubernetes to the microcopy in the frontend that is shipped with a headless CMS, engineering teams are choosing centralized platforms to maintain core components of their architecture. These tools don’t just eliminate redundant tasks — they empower product engineering teams to ship features faster, run experiments with less work, and focus less on infrastructure and more on the needs of the business.
It’s easier than ever to automate infrastructure provisioning and security policies. Just a year and a half after ChatGPT made “AI capabilities” a sudden requirement for every app, there are now countless “AI infrastructure as a service” companies. But what about a key ingredient to any cloud native architecture: APIs?
While countless tools streamline and automate other core components of modern cloud native architectures, we are still relying on individual, handwritten backends-for-frontends (BFFs) to deliver all of the capabilities of the backend to every single frontend.
Unless AI can write a sprawl of backend-for-frontends using REST by itself (can it?), we’ll need a better solution if we want to reduce boilerplate code and ship functionality across all of our interfaces faster.
Enter GraphQL Federation
To an individual API developer who is kicking the tires, GraphQL seems like a novel way to reduce overfetching and underfetching across clients. But when delivered at scale, GraphQL provides a key ingredient to improving developer velocity across engineering teams as well. GraphQL reduces friction between the frontend and the backend. When delivered at scale, GraphQL federation enables API platform teams to expose any number of APIs as a self-service and self-documenting graph called a “supergraph.” This supergraph abstracts API complexity and decouples the frontend from the backend, enabling both teams to work faster.
Here’s how it works:
- Backend developers contribute individual GraphQL APIs to the supergraph, which define types and their relationships as a schema.
- A process called composition combines these subgraph schemas into a single unified schema, either automatically or manually.
- Client teams are empowered to fetch all the data they need from the supergraph using a single endpoint — no matter where that data is stored.
GraphQL federation supports a better platform strategy in the following ways:
- Reducing bottlenecks to safely ship changes: Since GraphQL doesn’t require versions, teams can roll out more capabilities without a chain of passive-aggressive emails or endless meetings to prevent breaking changes.
- Reducing the cognitive load to consume an API: For client teams, GraphQL provides a declarative query language that enables client teams to fetch all the data they need. Simply use introspection to see what data is available, describe the data you need for your application and you’re off to the races.
- Reducing technical debt: You know what takes more time than writing a backend-for-frontend for a single interface? Writing 50 backend-for-frontends. GraphQL can serve any number of applications, so it’s not necessary to write or maintain a BFF for each one.
- Improving consistency across applications: When types and their relationships are clearly defined within the API itself, there’s less work to ensure consistency across interfaces.
- Abstract existing API complexity: GraphQL is often seen as an alternative to REST. But GraphQL can happily fetch data from other REST endpoints. It provides an abstraction layer that is custom-built to help teams deliver features faster.
When you’re thinking of your platform strategy, remember that it goes beyond infrastructure. There is often a lot of friction between the backend and the frontend that you can readily solve with GraphQL. Download the “Platform Engineering for APIs” white paper to learn why GraphQL is quickly becoming a language adopted by API platform teams to improve developer efficiency and velocity.
