Overview

Now that we're familiar with the federated architecture, let's dive into the developer platform that helps us build and manage it: Apollo GraphOS.

In this lesson, we will:

• Outline the overall process for how a supergraph gets made from start to finish

Managed federation

Managed federation is an approach to maintaining a supergraph. With managed federation, updates to our supergraph are handled by Apollo GraphOS.

GraphOS is the developer platform that helps us build, manage and scale our supergraph safely. GraphOS tracks and composes subgraph schemas in the registry, surfaces observability metrics, ensures safe schema delivery and more.

To interface with GraphOS, we use GraphOS Studio and the Rover CLI.

GraphOS Studio is the primary web interface for GraphOS. We can use Studio to create our supergraph, view schemas and metrics, and test out operations in the Explorer. If you've built a GraphQL server with us here on Odyssey, chances are you've used Studio before, or its free, lite version: Sandbox.

The Rover CLI is the primary command-line interface for GraphOS. We can use Rover to publish subgraph schemas, run schema checks from CI, and test out our supergraph in a development environment. We'll see these in action later on in the course!

We'll be working with both Studio and Rover as we use managed federation to bring our supergraph to life!

The managed federation workflow

At a high-level, the managed federation workflow looks like this:

1. Backend developers design and build their subgraphs.
2. Someone creates a new supergraph in GraphOS Studio.
3. Backend developers publish their subgraph schemas to the schema registry.
4. The schema registry automatically composes the subgraph schemas together into a supergraph schema, and makes it available via Apollo Uplink.
5. The router automatically polls Uplink for any new versions of the supergraph schema.

Let's take a closer look at each of these steps.

Step 1: Teams build their subgraphs

Backend teams independently build out their subgraph servers, using whatever language and framework they'd like.

Step 2: Creating a new supergraph in GraphOS Studio

Next, someone needs to create a new supergraph in Studio. Only one person needs to do this step.

Step 3: Publishing subgraph schemas

When we're happy with our subgraphs, we'll use the Rover CLI to publish each subgraph's schema to the schema registry. The schema registry is an Apollo-hosted version control system, which enables us to track changes to our schemas over time, such as which types and fields were added, modified, and removed. The registry powers almost every feature in Apollo GraphOS.

Step 4: Composing the supergraph schema

When the schema registry gets a new or updated version of a subgraph schema, it triggers a launch. A launch represents the complete process of making schema updates to a graph.

First, GraphOS will start to build the supergraph schema. It attempts to combine all of the schemas from its registered subgraphs into a single supergraph schema. This process is also known as composition. Pretty cool!

If composition fails, the schema registry displays an error in Studio, and the process stops there with a failed launch. No stress: we can use the error messages to fix the issue in our subgraph, and then try publishing the subgraph with Rover again.

If composition succeeds and there are no validation errors, the schema registry produces a supergraph schema.

The schema registry automatically sends the supergraph schema to an internal service within Studio called Apollo Uplink. Uplink is a server that stores the latest supergraph schema for each graph.

Step 5: The router polls Uplink for the latest supergraph schema

Next, we need the router to connect to the supergraph created in Studio in step 2.

The router automatically polls Uplink periodically to see if there's a new version of the supergraph schema.

Most of the time, the router sees that the supergraph schema stored in Uplink is the same version as the one it's already using. In this case, nothing changes.

But if the router sees that Uplink contains a new version of the supergraph schema, the router automatically updates to use the new version - with no need to restart the server, and no downtime! The launch completes successfully.

Now, any clients that communicate with the router will be able to reference and query the updated schema.

Here is the full managed federation workflow with the supergraph:

With our API's "source of truth", the supergraph schema, living in GraphOS, we'll get access to awesome features like the graph registry, observability metrics, safe schema delivery and more.

Practice

Key takeaways

• The client sends a GraphQL operation to the router. The router receives this request, figures out which subgraphs are responsible for resolving it, and sends the operations to the appropriate subgraphs. The subgraphs resolve the data and return it to the router, which then bundles it up to return to the client.
• After creating or updating a subgraph schema, developers use the Rover CLI to publish the subgraph schema to the Apollo schema registry.
• GraphOS composes the subgraph schemas into a supergraph schema, which the router uses to resolve incoming client requests.
• With managed federation, schema updates to the router are managed by GraphOS and happen with zero downtime.

Up next

It's time to compose a supergraph.