Variants in a supergraph

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, Apollo Studio 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 Apollo Studio, 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. Our 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.

Note: We'll be focusing on a federated graph, or supergraph, for this course, but graph variants can also be used for non-federated graphs.

Variants in the supergraph

Let's revisit our journey of a supergraph.

Journey of a supergraph. See below for a detailed image description.

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

An illustration of a subgraph facing two different paths: one to the `current` variant and the other to a `staging` variant

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.

An illustration of duplicate schema registries representing different variants, and how subgraphs can choose to publish to any of them.

Practice

Which of the following statements are true about graph variants in Apollo Studio?

The default graph variant is named defaultA graph variant represents an instance of a graph running in a specific environmentBoth federated and non-federated graphs can have graph variantsEach graph variant has its own schema, metrics, and change history

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.