4. Schema checks in a supergraph
7m

Overview

The Listings team has some exciting updates ready to publish to the , but they need to be confident in these changes before publishing them to the production . Fortunately, there's an Apollo Studio feature to help with that: !

In this lesson, we will:

  • Learn about two types of (build checks and checks)
  • Understand how fit into the overall process of updating a
  • Learn about the launch process in Apollo Studio

In this lesson, we'll focus mainly on the high-level overview of the process. The next lesson will dive more into the details of how to run each check.

What are schema checks?

Schema checks are a set of predefined tests that help identify potential failures caused by updates. They check for issues like incompatibilities between schemas or breaking existing client s. With , we can ensure that our schema changes won't cause issues when we deploy to production.

There are two types of : build checks and checks.

Build checks

Build checks validate that a 's changes can still compose successfully with other subgraph schemas in the .

Build checks are only available for federated graphs, because non-federated graphs aren't composed into a .

Illustration of subgraph characters being checked for composition

For example, if a new type is added to one , a build check determines whether that addition is compatible with the rest of the subgraphs in the . If it isn't, we need to investigate the error and fix it. We'll take a look at common composition errors later on in the course.

Operation checks

checks validate that a 's changes won't break any operations that existing clients send to the graph. Unlike build checks, operation checks are available for non-federated graphs in addition to federated graphs.

Illustration of Studio checking a schema against existing operations

For example, let's say a web client regularly sends a GraphQL query to retrieve data for its homepage. If a change involves adding a required to a in that query, it might break that client's existing ! An operation check helps us guard against this potential failure, listing out the affected operations and allowing the team to address them. We'll also take a look at an example of this later on in the course.

How to run schema checks

There are two main ways to run . We can run schema checks locally, using the CLI. We can also integrate schema checks into our CI pipelines to run automatically (which lets us do things like block merging any pull request that fails schema checks). We'll get to the pipeline stuff later in the course. For now, we'll focus on running schema checks locally.

To perform a check for a , we use the CLI's rover subgraph check command. This runs a build check first, then an check, and finally outputs the results in the command line. It also reports the results to Apollo Studio, so you can view them from your graph's Checks page. We'll see in action in the next lesson.

Schema checks in the supergraph story

Let's revisit our story and zoom in to where occur and what happens when they fail, pass, or are actively overridden.

After making changes to a (whether that's adding, removing, or updating definitions), we first want to run locally using . For a , a build check happens first, then checks run.

First, validates that a 's changes can still compose successfully with the other subgraph schemas in the . By default, this check runs against the current of the graph, but we can also select any graph variant already registered in Studio.

If the build check succeeds, runs an check immediately after. This validates that the 's changes won't break any operations that existing clients send to the graph.

Illustration using Rover for a local build check, variants in the registry

If either check fails, provides a link to the Studio Checks page that contains more information about what went wrong.

If all the checks are successful, we can go ahead and follow the same process as before: we'll use to publish the to the .

Illustration of schema checks fitting into the story of a supergraph. See description in paragraphs above for full outline of the process.

While we're on the subject of publishing changes, let's take a moment to touch on a useful feature of Apollo Studio: a launch.

Launch process

By publishing to the , we've triggered a launch in Apollo Studio.

A launch represents the complete process of making updates to any of a graph. You'll already be familiar with some of the steps in a launch (we covered them in Voyage I), but there are a few new steps thrown in the mix to include our handy !

A launch starts with Studio attempting to compose the . If it fails, we'll see an error and the process stops there. Otherwise, a supergraph is produced. The supergraph schema is provided to Uplink and our will fetch the latest schema.

We've successfully completed our updates to the graph!

Illustration of launches and how they fit into the story of a supergraph. See description in paragraphs above for full outline of the process.

And that's what and the launch process look like in our .

Practice

Schema checks
There are two types of schema checks. Checks that validate if a subgraph's schema changes can still 
 
 successfully with other subgraph schemas are called 
 
, which are available for 
 
. Checks that validate a schema's changes against existing 
 
 sent by clients are called 
 
, which are available for 
 
.

Drag items from this box to the blanks above

  • non-federated graphs

  • operations

  • both federated and non-federated graphs

  • operation checks

  • combine

  • query checks

  • combination checks

  • build checks

  • federated graphs

  • supergraph checks

  • compose

Which of the following statements about launches in Apollo Studio are true?

Key takeaways

  • help identify potential failures caused by schema updates before they can cause issues in production. There are two types of schema checks: build checks and checks.
  • Build checks validate that a 's changes can still compose successfully with other subgraph schemas. These checks are only available for federated graphs.
  • checks validate that a 's changes won't break any operations that existing clients are sending to the graph. These checks are available for both federated and non-federated graphs.
  • To run a check, we use the rover subgraph check command.
  • A launch represents the complete process of making updates to any of a graph. It's triggered by a being published to the .

Up next

In the next three lessons, we'll see how work in our development workflow and how they can be automated in the CI/CD process.

Previous
Next

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.