5. Managed federation & the supergraph
3m

Overview

Our subgraphs are running locally, and it's time to see how they fit in with the rest of our architecture. Let's take a step back and look at the overall process for how a gets made, from start to finish, using managed federation.

In this lesson, we will:

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

The managed federation workflow

Managed federation is an approach to maintaining a . With managed federation, updates to your are handled by Apollo Studio and the , all with zero downtime for your - which we'll get to in a bit.

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 Apollo Studio.
  3. Backend developers publish their subgraph schemas to the Apollo 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

As we've already seen, when using a -first approach, the frontend and backend teams first agree on the types and s their will include. From there, we move to the backend to decide how to distribute those types and s across multiple subgraphs.

The schema agreement from earlier, with each field highlighted to show whether it belongs to the locations or reviews subgraph.

With all that in place, backend teams can independently build out their subgraph servers, complete with s, s, and s.

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 Apollo Studio

Next, someone needs to create a new in Studio, which will be used by all the subgraphs for this app. 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 that our subgraphs are looking slick, we'll use the Rover CLI to publish each subgraph's to the . The is an Apollo-hosted version control system, which enables us to track changes to our s over time.

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

Step 4: Composing the supergraph schema

When the gets a new or updated version of a subgraph , it starts a process called composition. The attempts to combine all of the s from the registered subgraphs into a single . Pretty cool!

Step 4: Composing the supergraph schema

If composition fails, the displays an error in Studio, and the process stops there. 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 fails, the schema registry displays an error in Apollo Studio

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

The automatically sends the to an internal service within Studio called Apollo Uplink. Uplink is a server that stores the latest 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 to create another server for the , which we 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!

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

Now, any clients that communicate with the will be able to reference and query the updated . But let's come back to that.

Here is the full managed federation workflow with the :

The full managed federation workflow

Practice

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

  • managed federation

  • resolvers

  • router

  • data source

  • supergraph schema

  • construction

  • composition

  • subgraphs

  • version control

Key takeaways

  • After creating or updating a subgraph schema, developers use the Rover CLI to publish the subgraph schema to the Apollo schema registry.
  • The Apollo schema registry 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 Apollo Studio and happen with zero downtime.

Up next

Awesome, we've learned how the subgraphs we've built are going to fit into our federated architecture. We're ready to get back to FlyBy and apply what we've learned.

Next up, we're going to use the Rover CLI to publish our subgraph s.

Previous
Next