💎 Benefits of a supergraph

From the perspective of a graph consumer, there's nothing special about a supergraph. It looks the same as any other graph that returns data when you query it. And that's great! It means we don't need to change a thing on the client side.

So then, what makes a supergraph “super”? A supergraph's true power lies on the backend for graph contributors and maintainers.

Let's return to our Catstronauts app to better understand why adopting a supergraph architecture is a good choice for us.

The graph we implemented for the Catstronauts app in Lift-off can be described as a monograph: a single GraphQL server with a single GraphQL schema. Whenever we want to make any changes to our graph, we update that server and schema. This has worked great for us so far, but what happens as our graph continues to grow?

Our big dream of adding the pilot license feature to Catstronauts Academy is no small feat. We'd need to implement user management, assessments, and progress tracking logic to get us there.

No need for psychic gifts to see what's lying ahead if we're not intentional about our choices from the start. Our app and schema grow in complexity, up to a point where they become brittle and difficult to manage, especially with multiple teams contributing to them.

A common good practice in software engineering is to avoid building one large “monolithic” system in favor of multiple smaller interconnected ones.

Starting with our codebase, instead of piling thousands of lines of code into a single large file, we modularize our code by creating small, maintainable, and focused modules in standalone files that we can import and reuse elsewhere. Ideally, we modularize right from the start instead of needing to refactor our project after it exceeds a manageable size.

There are loads of examples of this same trend: packages, containers, and microservices. Modularization is a popular pattern because it provides clear benefits.

And as you probably guessed, this pattern is also absolutely valid for graphs!

This modular approach for the graph—a federated architecture composed of multiple smaller graphs unified into one—is called the supergraph. Modularizing your architecture makes it easier to scale because developers can work on different parts of the graph without getting in each other's way. It's also more stable and secure, thanks to Apollo's advanced platform and tooling.

The supergraph also yields a ton of value down the line: separation of concerns, security, fine-grained control, checks, launches, performance, traces...

For more on those, check out the Voyage series. But, for now, it's time to explore what supergraphs are made of.

🧬 Supergraph DNA

A supergraph is composed of one or more subgraphs.

A subgraph looks almost identical to a monograph: it has its own server, schema, resolvers, and data sources. The big difference, as the name implies (sub-graph), is that it only “owns” a sub-set of the whole graph.

Consequently, clients don't directly interact with a subgraph as they would with a monograph. If they did, they would need to know which subgraph owns what and query each separately to reconstruct a full picture of the data. Not the client's problem! One of the reasons to use GraphQL in the first place is so that clients only have to interact with a single endpoint.

Enter the graph router!

The graph router (or just “router”) sits in front of the subgraphs and acts as the client entry point to the supergraph. It uses a special supergraph schema, which combines the schemas from all the individual subgraphs. (The supergraph schema is created through a process called composition.)

Clients query the router like they would any other GraphQL server. When the router receives an incoming request, it uses the supergraph schema like a map to figure out which subgraph can resolve each field. Then the router's job is to interact with the appropriate subgraphs, construct a single complete response, and return the data to the client. Teamwork at the graph level!

(Speaking of teamwork, with a supergraph in place, development teams are now empowered to build and grow their subgraph within their own codebase, instead of all teams constantly needing to modify the exact same server and schema. Huge productivity and developer experience boost!)

The scope of our Catstronauts app is still small at this point. That's great because we won't need to make many changes to convert its graph into a supergraph.

Up next, we'll modify our current monograph to adopt the supergraph architecture and then compose it with an additional subgraph.