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 (
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.
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.
- 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.
In the next lesson, we'll create a graph variant 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.