2. Super Graph?

💎 Benefits of a supergraph

From the perspective of a graph consumer, there's nothing special about a . 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 “super”? A supergraph's true power lies on the backend for graph contributors and maintainers.

Illustration of a supergraph, made up of multiple hexagons representing subgraphs, with a crowd asking why so super?

Let's return to our Catstronauts app to better understand why adopting a 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 . 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 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 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 s are made of.

What benefits does supergraph provide?

🧬 Supergraph DNA

A is composed of one or more subgraphs.

A looks almost identical to a monograph: it has its own server, , s, and s. 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 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 (or just “router”) sits in front of the s and acts as the client entry point to the . It uses a special supergraph schema, which combines the s from all the individual s. (The schema is created through a process called composition.)

Clients query the like they would any other GraphQL server. When the router receives an incoming request, it uses the like a map to figure out which can resolve each . 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 in place, development teams are now empowered to build and grow their within their own codebase, instead of all teams constantly needing to modify the exact same server and . 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 .

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

What does a supergraph need to function?

Share your questions and comments about this lesson

Your feedback helps us improve! If you're stuck or confused, let us know and we'll help you out. All comments are public and must follow the Apollo Code of Conduct. Note that comments that have been resolved or addressed may be removed.

You'll need a GitHub account to post below. Don't have one? Post in our Odyssey forum instead.