Overview

We now have schema checks in our toolbelt, so let's see them put into action for the changes in the listings subgraph.

In this lesson, we will:

• Review the code changes in the local dev environment
• Review value types and the @shareable directive in a schema
• Learn how to run a schema check with Rover locally

Reviewing the mockup

Let's take a look at what we need for Project Galactic Coordinates again.

We need the listing details page to display the galactic coordinates of a listing and its host. The galactic coordinates are shown as a combination of latitude and longitude values.

The Airlock team has two people working on this feature, one from each subgraph team:

• 👩🏽‍🏫 Lisa from the Listings team
• 👩🏽‍🚀 Achilles from the Accounts team

We'll be helping them incorporate what we've learned in the previous lessons (schema checks and graph variants) into their development process!

Changes in the local development environment

👩🏽‍🏫 Lisa from the Listings team has already started to work on this feature by making additions to the schema, resolvers, and data sources. Let's take a look at what they've worked on to get this feature off the ground.

The listings subgraph has a new type: GalacticCoordinates. This object type has a latitude and longitude (both non-nullable Floats).

The GalacticCoordinates type is an example of a value type. Value types are types that are reused and shared across multiple subgraphs. These types can be object types, enums, unions, or interfaces. We've seen an example of an interface as a value type in Voyage II.

Right now, the GalacticCoordinates object type is only used in the listings subgraph, but remember that we'll also want to show the host's location, which belongs in the accountssubgraph. The @shareable directive will enable both subgraphs to resolve this type.

Lisa will need to add the @shareable directive to the GalacticCoordinates type.

Finally, Lisa also added one more field to the Listing entity: coordinates. This field returns the GalacticCoordinates type.

Lisa has also implemented the code for both the resolvers and data sources to retrieve the correct data for this new field.

Awesome, these changes should get us started! Let's revisit the CI workflow for the next step: pushing the code to GitHub and opening up a PR.

But wait! Don't forget we have a new item in our toolbelt: schema checks. We can run a schema check locally before pushing up our code. This will enable us to catch and address any errors related to composition or existing operations.

Running a local schema check

To run a local schema check, we'll use the rover subgraph check command with the following parameters:

We'll want to check our local subgraph changes against the staging variant, giving it the path to our listings.graphql schema file and the name of the subgraph, listings. After replacing the parameters with our subgraph's values, the command looks like this:

Because Airlock is a supergraph, build checks will run first, then operation checks.

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

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

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

Let's think back to our development process. We've done the first step, and we've even improved our flow by adding in a local schema check.

Practice

Key takeaways

• We use the rover subgraph check command to perform schema checks locally.
• The @shareable directive enables multiple subgraphs to resolve a particular object field (or set of object fields).

Up next

Let's continue to improve our workflow. In the next lesson, we'll add schema checks to our CI pipeline so that they can run automatically whenever a PR is created.