11. Schema checks
5m

Overview

We've seen our compose locally, and our changes are ready for the next stage. To bring our recommendedPlaylists feature into our , we need to tell about how our schema has changed!

We could just merge our changes and publish them to , but let's take a pause and first validate that these changes won't break anything. We're responsible developers, after all!

In this lesson, we will:

  • Learn about the types of
  • Understand how fit into the overall process of updating a
  • Run a schema check locally using the
  • Inspect the results of a schema check in Studio

What are schema checks?

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

We'll talk about three types of : build checks, checks, and linter checks.

Build checks

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

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.

Illustration of subgraph characters being checked for composition

Operation checks

Operation checks validate that a schema's changes won't break any that existing clients send to the .

For example, let's say a web client regularly sends a to retrieve data for its homepage. If a schema change involves adding a required to a in that , it might break that client's existing if it doesn't include that argument! An operation check helps us guard against this potential failure, listing out the affected operations and allowing the team to address them.

Illustration of Studio checking a schema against existing operations

Linter checks

Linter checks analyze your proposed schema changes for violations of formatting rules and other best practices. provides a set of default rules you can configure to suit your team's conventions. You can see a full list of rules in the Apollo documentation.

Some common schema conventions include: writing names in camelCase, type names in PascalCase, and enums in SCREAMING_SNAKE_CASE.

rover subgraph check

We can run these checks right from the command line using . Rover assesses our local changes for how they'll impact what we've already got in production. Its output will tell us everything we need to know—and what we need to fix!—before publishing our changes.

To perform a schema check for a , we use the rover subgraph check command with the following parameters:

rover subgraph check <GRAPH_REF> \
--schema <SCHEMA_FILE_PATH> \
--name <SUBGRAPH_NAME>

This command runs a build check first, then an check, then a linter check, and finally outputs the results in the command line. It also reports the results to Studio, so we can view them from your 's Checks page.

Running schema checks

Let's give it a try! We made schema changes by adding a new to an in the previous lesson (Recipe.recommendedPlaylists), so let's make sure those changes are safe before pushing them up to our schema registry.

First, let's regenerate the schema file. In a new terminal window, run:

dotnet run -- schema export --output schema.graphql

We should see a few additions to our schema.

schema.graphql
type Recipe @key(fields: "id") {
"A list of recommended playlists for this particular recipe. Returns 1 to 3 playlists."
recommendedPlaylists: [Playlist!]! @requires(fields: "name")
id: ID!
name: String @external
}
#...
union _Entity = Recipe | Playlist

We'll also need our . We can find this value in Studio, at the top of the 's README page, or grab it where we stored it in the Router/.env file.

Next, let's open up a new terminal and paste in the rover subgraph check command. Make sure you replace the parameters with your own values.

rover subgraph check GRAPHREF@GRAPHVARIANT \
--schema schema.graphql \
--name soundtracks

After the process completes, we can see a report of the schema changes. The terminal output shows the following:

Checking the proposed schema for subgraph soundtracks against Music-Matcher@current
There were no changes detected in the composed API schema, but the core schema was modified.
Operation Check [PASSED]:
Compared 1 schema changes against 2 operations.
┌────────┬─────────────┬───────────────────────────────────────────────────┐
│ Change │ Code │ Description │
├────────┼─────────────┼───────────────────────────────────────────────────┤
│ PASS │ FIELD_ADDED │ type `Recipe`: field `recommendedPlaylists` added │
└────────┴─────────────┴───────────────────────────────────────────────────┘

The first column indicates whether each change passed or failed the check. The second column indicates the type of change we made, such as FIELD_ADDED. The last column provides a more detailed description of the change, such as what exact type was created and what was added under the type.

Awesome, we have no errors! We can tell that the checks passed, because each row in the output table has a PASS status. The schema changes were also compared against the number of existing client , and no breaking changes were detected.

We can check out the results of this schema check (and any past checks) in Studio too! adds a link to this specific check at the end of its message.

Head over to your in Studio and navigate to the Checks page. You'll see the same results reflected there.

https://studio.apollographql.com

The Studio Checks page showing the results of the latest schema check

https://studio.apollographql.com

Details of a particular check in Studio

Optional: A failed check

For fun, let's see what would have happened if one of our checks failed.

Open up the schema.graphql file and find the Recipe.recommendedPlaylists . Change the lowercase r to a capital R so it says RecommendedPlaylists.

schema.graphql
RecommendedPlaylists: [Playlist!]! @requires(fields: "name")

In a terminal window, run the schema check again.

rover subgraph check GRAPHREF@GRAPHVARIANT \
--schema schema.graphql \
--name soundtracks

After the process completes, we can see a report of the schema changes. The terminal output shows the following:

Checking the proposed schema for subgraph soundtracks against Music-Matcher@current
There were no changes detected in the composed API schema, but the core schema was modified.
Operation Check [PASSED]:
Compared 1 schema changes against 2 operations.
┌────────┬─────────────┬───────────────────────────────────────────────────┐
│ Change │ Code │ Description │
├────────┼─────────────┼───────────────────────────────────────────────────┤
│ PASS │ FIELD_ADDED │ type `Recipe`: field `RecommendedPlaylists` added │
└────────┴─────────────┴───────────────────────────────────────────────────┘
View operation check details at: [STUDIO LINK]
Linter Check [PASSED]:
Resulted in 1 warning.
┌─────────┬─────────────────────────────┬──────┬─────────────────────────────────────────┐
│ Level │ Coordinate │ Line │ Description │
├─────────┼─────────────────────────────┼──────┼─────────────────────────────────────────┤
│ WARNING │ Recipe.RecommendedPlaylists │ 45 │ Field names should use camelCase style. │
└─────────┴─────────────────────────────┴──────┴─────────────────────────────────────────┘
View linter check details at: [STUDIO LINK]

We can see that our checks passed, and so did the linter checks, but with a warning: Field names should use camelCase style. We can view the check results in Studio as well.

https://studio.apollographql.com

Details of a failed linter check in Studio

Note: By default, all linter rules are set to "Warn". To view and change the severity of a rule, click "View Configuration". The full list of rules and their severity can be changed on that page.

Before we forget, let's revert that recommendedPlaylists change to get our checks passing again!

schema.graphql
recommendedPlaylists: [Playlist!]! @requires(fields: "name")

Practice

Types of schema checks
Schema checks identify potential failures from proposed schema changes. 
 
 checks validate that a schema follows GraphQL conventions. 
 
 checks validate that existing client operations won't break. 
 
 checks validate that the supergraph schema will still compose successfully.

Drag items from this box to the blanks above

  • Subgraph

  • Deprecated

  • Build

  • Linter

  • Field

  • Operation

Which of the following information does the rover subgraph check command need?

Key takeaways

  • help identify potential failures caused by schema updates before they can cause issues in production.
  • Build checks validate that a 's schema changes can still compose successfully with other .
  • checks validate that a schema's changes won't break any operations that existing clients are sending to the .
  • Linter checks validate that a schema follows formatting rules and conventions.
  • To run a schema check, we use the rover subgraph check command.
  • We can inspect the results of a schema check through the terminal or in the Studio Checks page.

Up next

Using GraphOS tools like Rover and Studio, we've validated that our schema changes are safe and don't break anything! 🎉 It's time to publish our changes to our supergraph's graph registry.

Previous

Share your questions and comments about this lesson

This course is currently in

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