2. Variants in a supergraph
3m

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 in a separate, safe environment (like our staging environment).

Right now, we only have the production version of the 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, has a feature for just that: graph !

In this lesson, we will:

  • Learn what a is
  • Learn how help our development workflow

What are graph variants?

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

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

Using 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 and connect it to the staging version of our (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 , or , for this course, but graph can also be used for non-federated graphs.

Variants in the supergraph

Let's revisit our journey of a .

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

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

We also have the option to choose which to publish a to. If we don't specify a variant name, our changes are published by default to the current . (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 to a , the rest of the story stays the same! This variant provides its schema to Apollo Uplink, which the can then fetch.

We can have as many as we want. This makes it easy to spin up new 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 GraphOS?

Key takeaways

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

Up next

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

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.