Join us from October 8-10 in New York City to learn the latest tips, trends, and news about GraphQL Federation and API platform engineering.Join us for GraphQL Summit 2024 in NYC
Docs
Start for Free

Next Steps for Your Supergraph

Get the most out of GraphOS


After you create a supergraph with , read below to learn about some of the next steps you should take to get the most out of it and the entire GraphOS platform.

NOTE

You should always start by installing the Rover CLI. Otherwise, you can perform the steps described on this page in any order.

First, install the Rover CLI!

The is the primary command-line interface for interacting with . You'll use Rover both locally and in CI environments to perform a variety of actions on your and its individual .

Install Rover, then return to this article.

Run your supergraph locally

See this article.

Subgraph actions

Update a subgraph schema

When you first set up your cloud supergraph, GraphOS Studio fetches your existing API's schema. Your existing API becomes the first in your supergraph:

Your infrastructure
GraphOS
Subgraph A
(Your GraphQL API)
Router
Clients

This initial schema fetch is a one-time action to help you get started. Whenever your API's schema changes, Studio doesn't automatically fetch it again. This means your doesn't know about those changes. Clients can't include any new schema in their queries until your router does know about the changes!

Whenever you update your subgraph's schema, you need to publish those changes with the Rover CLI. Learn about publishing subgraph schemas.

After learning about the publishing process, you should integrate it into your CI workflow.

Add another subgraph

One of the most powerful features of a supergraph is that it can combine multiple GraphQL APIs into a single graph:

Your infrastructure
GraphOS
Subgraph A
Subgraph B
Subgraph C
Router
Clients

With this architecture, different teams in your organization can each maintain their own subgraph. This helps teams work in parallel, because they aren't all contributing to the same single codebase.

1. Build your new subgraph

See Creating a new subgraph.

2. Add the subgraph to your supergraph

See Adding a new subgraph.

Add another variant

Most have multiple , each of which represents that supergraph running in a different environment (for example, production, staging, development).

If your supergraph runs in multiple environments, you should create a different for each.

Learn how to create variants.

Enable federation features

use an architecture called . Federation is at its most powerful when your subgraphs share responsibility for some of your schema's types, instead of defining mutually exclusive types and fields.

To take full advantage of federation features, each of your subgraphs needs to use a library that conforms to the Apollo Federation subgraph specification. Fortunately, many popular server libraries do!

  1. To check whether your current GraphQL server library supports the subgraph specification, see this article.
    • If your library does support the spec, consult its documentation to learn how to enable its federation support. For , see this article.
    • If your library doesn't support the spec, consult the library list to find an alternative in your preferred programming language.
  2. Enable federation support for all your subgraphs and deploy the updated subgraphs to your environment.

After you make these changes, you can start using powerful federation features in your subgraphs, including:

Set up continuous delivery

Every time you want to make changes to one of your subgraphs, you should do the following:

  1. Verify that your proposed changes won't break your supergraph or any of your existing clients.
  2. Whenever you deploy verified changes, always publish your updated to GraphOS as part of that deployment.

Disable client-subgraph communication

With a supergraph architecture, clients should never your individual subgraphs directly. Instead, they should always query the router! This means your subgraphs can (and should) reject incoming requests from any source besides the router.

Your infrastructure
GraphOS
Subgraph A
(Your GraphQL API)
Router
Clients

How you choose to configure this access control depends on your GraphQL server library and your particular infrastructure.

⚠️ CAUTION

Make sure any existing clients that communicate directly with your API are updated to communicate with your router before you begin rejecting direct requests!

For more information, see Securing your subgraphs.

Studio actions

Configure notifications

GraphOS can send you various types of notifications via a few different channels (including Slack and PagerDuty). These notifications can include a daily metrics report, schema change updates, and experimental performance alerts. Set up notifications.

Invite team members

If you've created a Studio organization to collaborate with your team, invite your team members from the organization's Members tab.

Client actions

Add identification headers to your clients

A supergraph variant's Clients page enables you to view metrics, segmented by your different clients:

Client awareness overview

To get the most out of this feature, each of your client applications should set values for the following HTTP headers in each request they send to your router:

  • apollographql-client-name
  • apollographql-client-version
Previous
Self-Hosted Setup
Next
Creating a New Subgraph
Rate articleRateEdit on GitHubEditForumsDiscord

© 2024 Apollo Graph Inc., d/b/a Apollo GraphQL.

Privacy Policy

Company