Overview

New features are exciting, and we're itching to get Project Galactic Coordinates out into the world. But we need to take care not to break existing functionality while giving clients a chance to test out these new queries and fields in a separate, safe environment (like our staging environment).

Right now, we only have the production version of the supergraph schema in the registry. Ideally, what we want is something similar to our Heroku setup: separate environments for staging and production versions of our graph, so that we can test out our schema changes before publishing them to our live site. Luckily, GraphOS has a feature for just that: graph variants!

In this lesson, we will:

• Learn what a graph variant is
• Learn how graph variants help our development workflow

What are graph variants?

A graph variant is an instance of a graph that runs in a specific environment (such as staging or production). In GraphOS, each variant of a graph has its own schema, metrics, change history, and operation history.

So far, we've been working with only one version of our graph: the version that's currently running in production. This is actually our very first variant, and its default name is current. The GraphOS Router running in production is connected to this graph variant through the environment variables we had previously set up (APOLLO_KEY and APOLLO_GRAPH_REF).

Using graph variants helps us test and validate changes to our schema without committing to them right away in our production environment. The way you use graph variants can vary depending on your team and company's use cases, along with your deployment practices.

For Airlock, we want to set up a staging graph variant and connect it to the staging version of our router (using the corresponding environment variables). We'll look at how to do this in the next lesson.

Variants in the supergraph

Let's revisit our journey of a supergraph.

We learned in Voyage I that teams build their own subgraphs and publish their subgraph schemas to the Apollo schema registry.

We also have the option to choose which variant to publish a subgraph schema to. If we don't specify a variant name, our changes are published by default to the current variant. (We'll take a closer look at how to publish to a specific variant in the next lesson.)

After we publish the subgraph to a variant, the rest of the story stays the same! This variant provides its schema to Apollo Uplink, which the router can then fetch.

We can have as many variants as we want. This makes it easy to spin up new graph versions to test and play with before committing to the production environment.

Practice

Key takeaways

• A graph variant represents an instance of a graph that runs in a specific environment.
• The managed federation process stays the same as before, with the added option of choosing which variant to publish a schema to.
• Graph variants are available for both federated and non-federated graphs.

Up next

In the next lesson, we'll create a graph variant for the staging environment.