5. Local schema checks
5m

Overview

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

In this lesson, we will:

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

Reviewing the mockup

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

Mockup of the Airlock listing page, showing the location information (latitude, longitude) under the location details. It also shows the location information of the listing owner (the host).

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.

Note: You won't be coding along with the course, but pay attention to the steps and concepts we're covering as we implement these code changes!

The Airlock team has two people working on this feature, one from each 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 ( and graph s) 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 has a new type: GalacticCoordinates. This has a latitude and longitude (both non-nullable Floats).

subgraph-listings/schema.graphql
"Coordinates in the galaxy"
type GalacticCoordinates {
latitude: Float!
longitude: Float!
}

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

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

Note: If you completed Voyage II, we briefly covered the @shareable directive in our discussion on field sharing. Note that value types that are s (such as GalacticCoordinates) need to use the @shareable , but interfaces (such as what we covered in Voyage II) do not.

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

subgraph-listings/schema.graphql
"Coordinates in the galaxy"
type GalacticCoordinates @shareable {
latitude: Float!
longitude: Float!
}

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

subgraph-listings/schema.graphql
type Listing @key(fields: "id") {
# … other listing fields
"Where this listing is located in the galaxy"
coordinates: GalacticCoordinates
}

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

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.

Diagram showing the CI workflow. See detailed image description below.

But wait! Don't forget we have a new item in our toolbelt: . 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 s.

Diagram showing the CI workflow, with an additional step inserted. See detailed image description below.

Running a local schema check

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

rover subgraph check <GRAPH_NAME>@<GRAPH_VARIANT> \
--schema <SCHEMA_FILE_PATH> \
--name <SUBGRAPH_NAME>

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

rover subgraph check airlock-managed-fed@staging \
--schema "listings.graphql" \
--name listings

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

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

Checking the proposed schema for subgraph listings against airlock-managed-fed@staging
Check Result:
Compared 4 schema changes against 16 operations
┌────────┬─────────────┬─────────────────────────────────────────────────────┐
│ Change │ Code │ Description │
├────────┼─────────────┼─────────────────────────────────────────────────────┤
│ PASS │ TYPE_ADDED │ type `GalacticCoordinates`: created │
├────────┼─────────────┼─────────────────────────────────────────────────────┤
│ PASS │ FIELD_ADDED │ type `GalacticCoordinates`: field `latitude` added │
├────────┼─────────────┼─────────────────────────────────────────────────────┤
│ PASS │ FIELD_ADDED │ type `GalacticCoordinates`: field `longitude` added │
├────────┼─────────────┼─────────────────────────────────────────────────────┤
│ PASS │ FIELD_ADDED │ type `Listing`: field `coordinates` 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 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 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 changes were also compared against existing client s, 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 check.

Diagram showing the improved CI workflow. See detailed image description below.

Practice

Which of the following information does the rover subgraph check command need?
Which types of schema checks does the rover subgraph check command run on a non-federated graph?

Key takeaways

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

Up next

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

Previous

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.