3. Publishing to a graph variant


Awesome, we know how can be useful in our development flow, so let's put them to use. In this lesson, we will:

  • Create a staging
  • Learn how to push a to a graph
  • Access and explore in

Creating a staging variant

Right now, both the staging and production versions of the are using the production version of the . This means that when we publish changes to our staging , the schema used by our live production router also changes. And that's not great, because if our changes accidentally break something, things will be broken in both our staging and production routers. We need a staging for our staging version of the to use.

Let's take a look at how to create a staging . We'll start by setting up the staging with our production 's current state, so that we have a baseline to work from before we make our feature additions.

To create a new , we'll use the again. In fact, you're probably already familiar with the command we'll use: rover subgraph publish.

You might recall that the first of this command is the graph ref. The is the name of the graph, followed by @ and the name of the .


In Voyage I, we used the default current , but we can also specify a different variant. In this case, we'll use the name staging. If this doesn't already exist, will create it for us.

Here's how we'd publish the accounts to the staging of our :

rover subgraph publish airlock-managed-fed@staging \
--schema "accounts.graphql" \
--name accounts \
--routing-url "https://staging-airlock-accounts.com"

Note that the routing-url value points to the 's staging environment, not the production environment.

After running the rover subgraph publish command above, we'll see this in the terminal:

Publishing SDL to airlock-managed-fed@staging (subgraph: accounts)
using credentials from the default profile.
A new subgraph called 'accounts' for the 'airlock-managed-fed@staging' graph was created.
The supergraph schema for the 'airlock-managed-fed@staging' graph was updated,
composed from the updated 'accounts' subgraph.

After the schema is published to the staging , Studio will reflect this new addition. Under the 's name on the homepage, we can see a new variant has been added with the name staging.

Screenshot of Studio showing the staging variant in the list of variants.

We can click on the new staging to see the current schema for this . So far, it only consists of the accounts that we just registered.

Screenshot of Studio showing the staging variant with the accounts subgraph registered.

We'll also need to register all the other to the new staging : listings, bookings, reviews, and payments. The values for the schema, name, and routing-url options will differ for each, but the name and the will stay the same!

After publishing all the other , we can see them in our staging schema:

Screenshot of Studio showing the staging variant with all five subgraphs registered.

Awesome, the staging is now set up with all of the for Airlock! Right now, the staging schema is in the exact same state as the current schema. We've got our baseline ready before we start making feature additions or schema changes.

The last thing we need to do is make sure the staging is connected to the endpoint for the staging .

We can do this in the 's homepage by clicking on Connection Settings, and setting the endpoint for the staging URL.

Screenshot of Studio showing the Connection Settings modal, where the staging router endpoint is set

All right, we're ready to proceed with our changes for Project Galactic Coordinates.


Which of these is the correct way to publish a subgraph schema to a specific variant?

Key takeaways

  • We can publish a schema to a specific by using the command rover subgraph publish and specifying the name after the @ symbol in the .

Up next

The Listings Team has been hard at work, and they're now ready to share their schema updates so that other teams can also start contributing to Project Galactic Coordinates.

In the next lesson, we'll see how they can use schema checks to confidently push their schema changes to the registry.


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.