2. Managed federation with GraphOS


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

In this lesson, we will:

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

Managed federation with GraphOS

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

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

To interface with , we use and the .

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

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

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

The managed federation workflow

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

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

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

Step 1: Teams build their subgraphs

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

An illustration showing the first step of the process: backend teams can independently build out their subgraph servers, complete with schemas, resolvers, and data sources.

Step 2: Creating a new supergraph in GraphOS Studio

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

Step 2: create a new deployed graph in Apollo Studio where the subgraphs can be registered

Step 3: Publishing subgraphs

When we're happy with our , we'll use the 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 were added, modified, and removed. The registry powers almost every feature in .

Step 3: publish each subgraph's schema to the Apollo schema registry

Step 4: Composing the supergraph schema

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

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

Step 4: Composing the supergraph schema

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

If composition fails, the schema registry displays an error in Apollo Studio

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

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

The schema registry automatically sends the supergraph schema to an internal service within Studio called Apollo Uplink

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

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

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

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

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

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

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

Here is the full workflow with the :

The full managed federation workflow


Managed federation process
Every supergraph includes one or more 
, each of which has its own schema. With 
, each of these schemas is published to the Apollo schema registry. Whenever a subgraph schema is published, the schema registry triggers a process called 
. If successful, this process results in the creation of a 
, which is then fetched by the supergraph's 
 via periodic polling.

Drag items from this box to the blanks above

  • version control

  • data source

  • supergraph schema

  • subgraphs

  • router

  • composition

  • construction

  • resolvers

  • managed federation

Key takeaways

  • After creating or updating a , developers use the to publish the subgraph schema to the schema registry.
  • composes the into a , which the uses to resolve incoming client requests.
  • With , schema updates to the are managed by and happen with zero downtime.

Up next

Let's tackle the first step in our process: preparing our !


Share your questions and comments about this lesson

This course is currently in

. 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.