Updating your graph safely
Upgrade your components in the recommended order to avoid errors
Your supergraph consists of multiple components that are each versioned independently:
- The router is powered by a particular version of the Apollo Router.
- This is true for all supergraph types (cloud and self-hosted).
- The GraphOS build pipeline uses a particular version of Apollo Federation to compose your router's supergraph schema.
- If you use the Rover CLI to compose your supergraph schema, this is true for Rover as well. In this case, you effectively maintain your own build pipeline.
- Your subgraph schemas might each use special directives that were first introduced in a particular version of Apollo Federation.
These components each target support for a particular version of Apollo Federation, the architecture that underpins every supergraph. Because of this, it's important to make sure these various Federation versions remain compatible with each other as you make updates to individual components.
Recommended update order
To avoid runtime or composition errors, your supergraph's components should always maintain the following relationship between their targeted Apollo Federation versions:
(Router fed. version) ≥ (Build Pipeline fed. version) ≥ (Subgraph fed. version)
To maintain this relationship, always update these supergraph components in order from left to right:
1. Update your router
The method you use to update your router depends on which type of supergraph you have:
If you have a self-hosted supergraph, you download the latest Apollo Router binary in every environment where your router runs.
If you have a serverless cloud supergraph, GraphOS automatically updates your router to the latest supported version whenever that version changes.
You can see which Apollo Router version you're running from the Cloud Router section of your variant's Settings page in Studio:
For details on each Apollo Router version's corresponding Apollo Federation version, see this article.
2. Update your build pipeline
Whenever you make an operational change to your graph (such as publishing changes to a subgraph schema), GraphOS initiates a build that composes your graph's new supergraph schema. From Apollo Studio, you can configure which version of Apollo Federation the build pipeline uses to perform this composition.
GraphOS enables you to choose between minor versions of Federation (such as
2.1). Each option automatically uses the latest supported patch release of that minor version (such as
Although patch release updates are automatic, you must manually move a graph's build pipeline to a different minor release.
Go to your variant's Settings page, then find the General > Build Configuration section.
Click Edit Configuration. The following dialog appears:
Select a Federation version from the Supergraph Pipeline Track dropdown and click Save.
GraphOS immediately initiates a new build using the selected Federation version, and all future builds also use the selected version.
Composing with the Rover CLI
If you host your own Apollo Router instance, you can use the Rover CLI to compose its supergraph schema via the
rover supergraph compose command.
⚠️ Performing composition with Rover is not recommended. Instead, perform composition via the GraphOS build pipeline to help ensure a consistent schema delivery process across all of your graph's environments.
If you do perform composition with
rover supergraph compose, the command uses the exact version of composition you specify via the
federation_version key in the YAML configuration file you pass:
rover supergraph compose --config ./supergraph.yaml
federation_version: =2.3.2subgraphs:# ...
This value must target a specific patch release (
2.3.2, etc.), and it must start with an equals sign (
⚠️ Important: If you don't provide a value for
federation_version, Rover prints a warning and chooses a composition version according to this logic. This is dangerous! Rover might use a newer composition version than what your router supports, resulting in a supergraph schema that causes the router to fail on startup.
3. Update subgraph schemas (as needed)
After both your router and your build pipeline support a particular minimum version of Apollo Federation, your subgraphs can use features that were first introduced in that version.
You don't need to update any subgraph schema that doesn't use newly introduced Apollo Federation features. Different subgraph schemas can target different Federation versions as needed. Ultimately, your build pipeline determines which version of composition is actually used to create the supergraph schema.
As an example, the
@interfaceObject directive was first introduced in Federation 2.3. To start using this directive in a subgraph, do the following:
Make sure your chosen subgraph library has added support for the
@interfaceObjectdirective by consulting this table.
- If your library doesn't yet support the directive, reach out to its maintainers about adding support.
Upgrade to the latest version of your subgraph library to make sure you're using a version that supports
Modify the following
@linkdirective in your subgraph schema (or add it if it isn't present yet):extend schema@link(url: "https://specs.apollo.dev/federation/v2.3",import: ["@key", "@shareable", "@interfaceObject"])
Notice that the
v2.3of the Apollo Federation spec, and
@interfaceObjectis included in the
@interfaceObjectdirective to relevant locations in your subgraph schema.
Because you've already updated your router and build pipeline, the next time you deploy your subgraph and publish its schema to GraphOS, every component in your supergraph will be prepared to interact with a schema that includes the
@interfaceObject directive you've added.
Why is this update order necessary?
GraphOS supergraphs use the Apollo Federation 2 architecture. Federation 2 is itself a versioned technology (2.2, 2.3, etc.), and each version introduces changes and additions to the set of supported subgraph directives.
Each version of the Apollo Router is compiled against a particular version of Federation 2 (for details, see this table). Any given router version is backward compatible with previous versions of Federation. However, it isn't compatible with newer versions.
Therefore, it's important to update your router first, before any other supergraph component begins using a later Federation 2 version. Otherwise, you might cause your router to break by providing it a supergraph schema that it doesn't support.
Your graph's Supergraph Pipeline Track setting in Apollo Studio determines which version of Federation 2 is used to compose your supergraph schema. This composition process fails if one of your subgraph schemas uses a directive that was introduced in a Federation version later than your chosen pipeline track.
- In the case of a failed build, GraphOS continues to provide your router with the supergraph schema from the most recent successful build.
Finally, subgraph schemas are where you actually apply new Federation 2 directives. You need to update your subgraph library to a version that recognizes all directives that you use in your schema.
You perform this update last to make sure that every other component of your supergraph is prepared to interact with any newly introduced directives.