GraphQL is great in that it truly decouples the frontend from the backend, allowing developers to focus on data needs without being tied down by the specifics of the underlying APIs…or needing to be omniscient about which microservice needs to be hit up for which part of data.
This whole “single, unified API layer to fetch data from all your microservices” approach is perfect for enterprises that not only want the operational benefits of independent teams with a shared contract, but also, to create an enterprise ‘data pool’ that all teams can pull from to create new features and adapt to business pivots and changing client demands.
But such a distributed GraphQL setup is fraught with complexity. Schema stitching has a low barrier to entry, but involves a lot of manual work to bring together your different graphs. Federation, on the other hand, is the more scalable, composable approach that promotes better collaboration across service teams…but is a closed, proprietary solution owned by Apollo (Federation V2 started as MIT, then transitioned to the Elastic V2 license, which the OSI does not consider open-source).
This brings us to what I want to talk about today. How do you build a business around distributed GraphQL if you are perpetually bound to a single-vendor ecosystem?
The time is nigh for Open Federation — a joint effort by WunderGraph and The Guild to create a proper specification for federated GraphQL that is truly free and open-source under the MIT license.
How We Got Here: A Brief History of Federation
With the rise of microservices-based architectures, companies started breaking down large monolithic applications into smaller, independently deployable services, each focused on specific business capabilities, and exposing its own GraphQL schema. To thrive in this environment, GraphQL had to go beyond just flexibility and efficiency; it had to tackle distributed data and schema management challenges.
TL;DR: We needed to merge types and queries from various GraphQL services into a single schema — and so schema stitching grew organically as a grassroots solution to this specific problem of composition. With it, developers could create a gateway server that brought together multiple GraphQL schemas — each a service, and each completely independent and unaware of the “stitching”.
Schema stitching
This had its limitations. If two schemas defined types with the same name, it led to conflicts that developers had to manually fix, either by aliasing types or using custom resolvers. More importantly, stitching lacked a standardized way for services to declare how they could be composed together, and didn’t offer built-in support for dividing a single incoming operation into one or more operations (and ordering their execution) that were each resolvable by a single subgraph. You had to do all this work manually at the gateway level.
Recognizing these shortcomings, Apollo worked on Apollo Federation, open-sourcing it in 2019. It aimed to provide a more robust and standardized solution to the challenge of building federated GraphQL APIs.
Apollo Federation
Federation introduced a query planning process that allowed the gateway server (a Router) to decompose a query and route its parts to the appropriate services, improving query efficiency and reducing over-fetching. There’s also service awareness — each service could declare its capabilities and relationships with other services using a special SDL (Schema Definition Language) syntax. This made it easier to understand how services fit together in the federated graph.
It also introduced the concept of entity types, representing core business entities — resources, if you will — that could be shared amongst services. This allowed services themselves to declare which types they could reference, or even extend…and if these resources could have shared ownership, it meant better collaboration between teams, as opposed to the strictly decoupled nature of schema stitching.
Federation was a revolutionary new technology, completely different from anything we’ve had until now. It offered a standardized approach to schema composition, query planning, and service awareness. Federation, like nothing before it, let orgs confidently create, scale, and maintain complex, composed APIs that seamlessly integrated data from multiple sources, enabling them to adapt, evolve, and grow.
But then it moved to the Elastic V2 license.
This brings us to the present day, when the GraphQL landscape is at a perfect inflection point. The demand for federated GraphQL architectures is at an all time high — more and more companies want a unified interface into their heterogenous backends (REST, GraphQL, gRPC, Kafka/AsyncAPI, etc.) to create company-wide data pools for organic growth and adaptability — but Apollo Federation is not enough to meet those needs, because of a mix of the technical ambiguity of its specification, and critically, its licensing.
It’s evident that the GraphQL community needs an alternative solution. One that is not owned by any single vendor.
Enter Open Federation, a truly free and open-source approach that not only addresses these limitations, but also champions the principles of openness, accessibility, extensibility, and collaboration. Let’s look at Open Federation and how it’s poised to reshape the future of federated GraphQL.
Introducing Open Federation
This is a drop-in replacement for Apollo Federation that enables any vendor, at all, to implement (or extend) it for federated GraphQL solutions of their own, and contribute to a healthier, more diverse GraphQL ecosystem. Walmart, SAP, Tripadvisor, Neo4j, Tailor.tech, and many more companies have pledged their support for it.
The goal of Open Federation is to standardize the process of federation itself — everything from core concepts of subgraphs and federated graphs, to the directives that define them, to algorithms that are needed for query planning and execution, and in general, everything to do with bringing together (and validating) subgraphs into a composed, federated graph — and license all of it under MIT.
It aims to lay down an in-depth, canonical understanding of federated GraphQL, serving as a source of truth and a collaborative base for anyone who wants to implement federated APIs — or extend the specification however they choose.
The idea is to foster openness, making it easier for companies to adopt federated GraphQL, work on it, and add their knowledge to the base — all of which ultimately leads to innovations in the GraphQL ecosystem that haven’t been seen until now with Apollo’s single-vendor ecosystem.
The Three Tenets of Open Federation
1. A True Technical Specification
One of the biggest technical issues with Apollo’s Federation V2 specification is that it’s too vague. All it says is that your subgraph schemas must make a number of additions to be compatible with the Federation Gateway.
To be part of a federated graph, an implementing service must conform to the Apollo Federation specification, which exposes the service’s capabilities to the gateway, as well as to tools like Apollo Studio.
# ⚠️ This definition must be created dynamically! The union
# must include every object type in the schema that uses
# the @key directive (i.e., all federated entities).
union _Entity
scalar _Any
scalar FieldSet
scalar link__Import
scalar federation__Scope
enum link__Purpose {
"""
`SECURITY` features provide metadata necessary to securely resolve fields.
"""
SECURITY
"""
`EXECUTION` features provide metadata necessary for operation execution.
"""
EXECUTION
}
type _Service {
sdl: String!
}
extend type Query {
_entities(representations: [_Any!]!): [_Entity]!
_service: _Service!
}
directive @external on FIELD_DEFINITION | OBJECT
directive @requires(fields: FieldSet!) on FIELD_DEFINITION
directive @provides(fields: FieldSet!) on FIELD_DEFINITION
directive @key(
fields: FieldSet!
resolvable: Boolean = true
) repeatable on OBJECT | INTERFACE
directive @link(
url: String!
as: String
for: link__Purpose
import: [link__Import]
) repeatable on SCHEMA
directive @shareable repeatable on OBJECT | FIELD_DEFINITION
directive @inaccessible on FIELD_DEFINITION | OBJECT | INTERFACE | UNION | ARGUMENT_DEFINITION | SCALAR | ENUM | ENUM_VALUE | INPUT_OBJECT | INPUT_FIELD_DEFINITION
directive @tag(
name: String!
) repeatable on FIELD_DEFINITION | INTERFACE | OBJECT | UNION | ARGUMENT_DEFINITION | SCALAR | ENUM | ENUM_VALUE | INPUT_OBJECT | INPUT_FIELD_DEFINITION
directive @override(from: String!) on FIELD_DEFINITION
directive @composeDirective(name: String!) repeatable on SCHEMA
directive @interfaceObject on OBJECT
directive @authenticated on FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM
directive @requiresScopes(
scopes: [[federation__Scope!]!]!
) on FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM
# This definition is required only for libraries that don't support
# GraphQL's built-in `extend` keyword
directive @extends on OBJECT | INTERFACE
That’s all perfectly fine, but…this is only a list of scalars and directives that doesn’t provide a comprehensive specification for Federated GraphQL, like traditional GraphQL does for implementing GraphQL servers and clients. Instead, it’s a rulebook on how to structure your subgraph schemas to be compatible with Apollo tooling, and nothing else.
What if your GraphQL service doesn’t permit types that start with a ‘_’? What if it doesn’t support unions and/or custom directives? Well, then you’re just out of luck. The official Apollo Federation spec is about facilitating schema composition with a proprietary solution (Apollo), rather than giving you an actual understanding of what individual elements of Federation are, and how they are supposed to work together, so you can build your own solutions or workarounds.
Open Federation seeks to remedy this by defining and documenting a new, standardized approach to federated GraphQL. This means creating a clear, unambiguous, well-documented specification (and critically, opening it up to scrutiny and community review) that defines each directive that defines a subgraph or federated graph, how different GraphQL services can collaborate and federate their schemas, what a “Gateway” should mean in a federated GraphQL context, what it should do, how it’s supposed to route queries and decompose a single client query into subqueries that can each be resolved by a single subgraph, how the Gateway should combine and organize subquery data from various services into a cohesive response and send it back to the client, validation rules for composed graphs, and more.
Making this part of a canonical knowledge base helps developers across various projects and organizations to build federated APIs with a well-defined set of rules and practices, or their own implementation — Gateways/Routers, or their own extended spec altogether — and optimize it for their use case as they go.
2. Interoperability With The Existing Ecosystem
For Open Federation to grow, not only do its implementations have to retain cross-compatibility with each other, but they also have to interop with the existing dev ecosystem. Frequently, this means supporting the de-facto way organizations have done federated GraphQL — Apollo Federation — and all existing tooling around it (which includes CI/CD flows, schema registries, composition utilities like rover, and Federation-compatible subgraph libraries and gateways.)
Open Federation recognizes the significance of this ecosystem and aims to enhance it — adding specificity and subtracting ambiguity — but ensuring interoperability with federated GraphQL architectures and dev tools already in place.
This means that existing Apollo Federation users can adopt Open Federation as a drop-in replacement without significant disruption, or major rewrites. In fact, any Apollo Federation subgraph can be composed into an Open Federation graph, as the latter builds on top of existing federation-specific directives, further clarifying them.
Adopting Open Federation provides a path for organizations to migrate to a fully open-source solution while preserving their investments in tooling, workflows, and knowledge bases developed around Apollo Federation.
3. Extensibility for the Future
The Open Federation spec is a strong base that can be extended by any vendor to create new implementations of federated GraphQL, or new specifications altogether.
For example, if you’re an eCommerce platform, you’d need your federated Gateway to handle high volumes of concurrent requests, even during peak traffic. Rust is a language that has memory safety and low-level control, so your Gateway could use it to implement the Open Federation spec, modified and optimized for your specific use case.
What if your subgraphs needed an auth library that was NodeJS only? No problem, your Gateway could be written in NodeJS and still conform to the Open Federation spec. Now, your implementation is purpose-built for compatibility with the wider JS ecosystem, instead.
A federated GraphQL spec should never hold you back from how you want to work with GraphQL itself.
The perfect example of the kind of open ecosystem Open Federation promotes is GraphQL Fusion — a collaborative effort between ChilliCream, The Guild, Hasura, IBM, solo.io, AWS AppSync, and WunderGraph — which was built to solve the problem of organizations relying on a multitude of internal and external data services that are not only GraphQL. It goes above and beyond the capabilities of traditional federated GraphQL to cover diverse, real-world enterprise use cases, enabling them to build unified APIs for all of their data while still shielding the client from implementation details that lie beyond the gateway.
Shared Knowledge Breeds Innovation
Apollo has done a ton of work in improving the GraphQL ecosystem with its many open-source GraphQL projects like the Apollo Server and Client libraries, but there’s no denying that the Elastic license, combined with the Federation spec’s inherent ambiguity and a lack of proper documentation holds back widespread adoption of federated GraphQL architectures, and hinders the development of a healthy GraphQL ecosystem for all.
And a healthy GraphQL ecosystem is exactly what Open Federation was built for. An open, shared specification that is not owned and closed down by any single company, one that invites collaboration, serving as a foundation for multiple vendors to build services, solutions, and tooling around, leading to better competition — and more innovation.
