2. Variants in a supergraph


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

Right now, we only have the production version of the in the . 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 s!

In this lesson, we will:

  • Learn what a graph is
  • Learn how graph s 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 of a graph has its own , metrics, change history, and 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 , and its default name is current. Our running in production is connected to this graph through the environment s we had previously set up (APOLLO_KEY and APOLLO_GRAPH_REF).

Using graph s helps us test and validate changes to our 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 and connect it to the staging version of our (using the corresponding environment s). We'll look at how to do this in the next lesson.

Note: We'll be focusing on a federated graph, or , for this course, but graph s 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 s and publish their subgraph s to the Apollo .

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 to Apollo Uplink, which the can then fetch.

We can have as many s 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.


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

Key takeaways

  • A graph 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 to publish a to.
  • Graph s are available for both federated and non-federated graphs.

Up next

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


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.