We’ve had a busy month at Apollo. Over the last several weeks we’ve released some significant updates to the Apollo stack. Last month we shipped Federation 2, a sophisticated and more flexible approach to GraphQL composition. And last week we made Contracts generally available, a way to tailor your graph to specific use cases like mobile development or creating public GraphQL APIs.
Today we’re updating two more components of our stack: the GA release of Apollo Router, our new high-performance federation runtime written in Rust, and a new Studio build pipeline for delivering changes to a graph.
The reason we’ve been building these particular tools is that together, they implement an architecture that covers the essentials of what teams that have gone the furthest with GraphQL seem to need most. What we’ve seen and heard from developers building on Apollo has been remarkably consistent, across a range of organizations building many different kinds of products on the graph, working with a wide variety of languages and technologies.
The architecture that solves those needs now powers companies like Netflix, Walmart, Expedia, Zillow, RetailMeNot, Paypal, Major League Baseball, and many more. We think it’s time to give this architecture a name, and after talking about it with the developers that have pioneered this approach in their companies, we’re calling it the supergraph.
The principles of a supergraph
The essential ideas of the supergraph are going to be pretty familiar for users who’ve been following Apollo for a while. It really just comes down to three core principles.
1: a unified composition layer
The supergraph is a new way to think about GraphQL that goes beyond the technical benefits of replacing data fetching and BFF code with schema and queries. It’s a unified network of a company’s data, microservices, and digital capabilities that serves as the “composition layer” for the whole organization.
By bringing everything together to this common collaboration point, the supergraph empowers everyone to create richer, more engaging experiences for their users and customers.
2: modular architecture
The supergraph is built on a declarative, modular architecture. Just as React leverages this approach to scale UI development and Kubernetes leverages it to scale services deployment, it makes sense to want the same for the data layer as it grows beyond a single team.
That’s what Apollo Federation has always been about, letting you scale a graph without bottlenecking developers on a single monolith or creating a single point of failure.
Of course, modularity offers a lot of additional advantages along the way: programmable configuration, standardized tooling, analyzable query plans, strict validation at build-time instead of run-time, great support for heterogeneous environments, a structured on-ramp for new developers, and many more.
3: agile approach
The supergraph enables a bottom-up, agile approach. Traditionally, APIs tend to be fairly static. Because it’s so hard to change an API, the tendency is to waterfall a design that anticipates future requirements. But products change constantly, driven by evolving user requirements and feedback.
We’ve learned the importance of taking an agile approach to the supergraph, where every developer is empowered to publish changes into the schema to support their own product development and where actual use of the schema drives decisions about future iteration and improvement.
On to the supergraph
We’ve seen case after case of the supergraph architecture – a unified layer, made from modules, continuously evolving – emerging organically, at companies we respect and admire. So we’re focused on this idea of the supergraph and our ambition is to help every team have one. Here’s how all that we’ve been building helps with that goal.
Apollo Federation: build a supergraph
Apollo Federation is our open architecture for composing GraphQL services – what we call subgraphs – together into a single supergraph. Each subgraph is a self-contained component with its own schema, so it can be developed, tested, and deployed independently.
Rather than relying on custom code to combine subgraphs, subgraphs reference and extend each other through a principled set of primitives. Thanks to our incredible developer community, Federation supports subgraphs written in 20 programming languages and a growing number of GraphQL-native services and products.
Federation 2 builds on what we’ve learned working with supergraphs. It adds more complete support for the GraphQL spec including interfaces and certain uses of directives and eliminates much of the boilerplate code that came with Federation 1.
Federation 2 also streamlines collaboration on the supergraph with a flexible shared ownership model that allows multiple subgraphs to implement overlapping, complementary parts of types and schemas. New governance directives like @inaccessible, @shareable, and @override give teams fine-grained control over the composition process and resulting supergraph schema.
tldr; Federation is now more approachable and incrementally adoptable for anyone interested in moving to the supergraph, and it smoothly scales all the way up to thousands of developers collaborating on the largest, rapidly-evolving supergraphs. Check out the Federation quickstart to learn more.
Apollo Router: run a supergraph
So you’ve created a federated schema, but how do you run it? A supergraph runtime has to receive client requests, build an execution plan, route requests to the proper subgraphs, assemble the results back together and return it back to the client.
Like a relational database, it requires a sophisticated implementation that shields users from unwanted details of execution while still providing a principled way to analyze and control the system when necessary.
Our first supergraph runtime was Apollo Gateway, built on Node.js. While the Gateway is horizontally scalable, we think critical infrastructure like this is better written in a lower-level systems language that offers a smaller operational footprint.
That’s why we built Apollo Router, our next-generation supergraph runtime written in Rust. The performance advantages are significant: Apollo Router processes requests with 10x lower latency, 10x higher throughput, and 12x lower variance compared to its JavaScript predecessor. Take a look at the benchmark below to get a sense of how much better it is.
There are other benefits too, like an extension facility that lets you replace custom gateway code with configuration (this should sound familiar!) and comprehensive support for OpenTelemetry.
As of today, Apollo Router is generally available, free for anyone to use. Check out the Router docs to learn more.
Apollo Studio: deliver a supergraph
Apollo Studio is the final piece of a supergraph stack. Its delivery pipeline provides the validation, automation, and observability you need to deliver changes rapidly and safely, making it possible to constantly evolve the supergraph, particularly when teams leverage and extend each other’s contributions.
Schema Checks and Launches prevent breaking changes before they happen by automatically validating your supergraph schema in development and giving visibility into past and in-progress changes to the supergraph.
Previously only available on our Team and Enterprise plans, today we are making Studio’s delivery pipeline available to everyone.
What’s next for the supergraph
Adding it all up, we’re excited to get all these core components of the supergraph architecture in your hands. We’re excited to build with you and eager to work together to figure out what should come next!
Stay in our orbit!
Become an Apollo insider and get first access to new features, best practices, and community events. Oh, and no junk mail. Ever.
Make this article better!
Was this post helpful? Have suggestions? Consider so we can improve it for future readers ✨.