Set up a self-hosted supergraph

This tutorial gets you up and running with GraphOS and a self-hosted supergraph, using the Apollo Router. While you can run the router regardless of your Apollo plan, connecting the router to GraphOS requires an

Supergraph concepts

Before we get started, let's quickly cover what a self-hosted supergraph is.

A supergraph combines multiple GraphQL APIs into a single unified GraphQL service. The individual APIs in a supergraph are called subgraphs:

A separate service called the router sits in front of your subgraphs and provides the publicly accessible endpoint for your supergraph. Clients query the router, which distributes each query across the appropriate combination of subgraphs and returns the combined result.

The router uses a special GraphQL schema called the supergraph schema. This schema incorporates the types and fields in each subgraph schema, along with metadata that enables the router to correctly distribute queries across subgraphs.

A self-hosted supergraph is a supergraph with a router that you host and manage in your own infrastructure. This is in contrast to a

We'll cover these concepts in more detail as we proceed through the steps below.

1. Set up Apollo tools

This quickstart uses the following Apollo tools:

• GraphOS Studio: This is the primary web interface for GraphOS. Studio helps you monitor, manage, and collaborate on your supergraph.
• The Rover CLI: This is the primary command-line interface for GraphOS. Rover helps you interact with your graphs and their schemas.

Let's set these up first.

Create an Apollo account

To manage our supergraph with GraphOS, we need an Apollo account. Let's create one if you don't have one yet.

Complete the first step of

Create a graph in GraphOS Studio

After you create your Apollo account, create your first graph in GraphOS Studio by following these steps:

1. Go to your organization's Graphs tab in

   GraphOS Studio
   .

2. Click Create New Graph in the top right.

3. In the dialog that appears, specify an Organization and Graph title for your graph.

4. Leave the Graph Architecture as Supergraph (Default).

5. Click Next. A modal like the following appears:

6. Leave the Supergraph Pipeline Track dropdown set to its default value.

Your graph has been created!

Install the Rover CLI

Rover is Apollo's CLI for managing all kinds of graphs, including subgraphs and supergraphs. We'll use it throughout this quickstart.

Install the latest Rover release with the appropriate command for your system:

curl -sSL https://rover.apollo.dev/nix/latest | sh

iwr 'https://rover.apollo.dev/win/latest' | iex

After installing, run rover in your terminal with no arguments to confirm that it installed successfully. Verify that the printed version number matches the

Authenticate Rover with GraphOS

We'll use Rover to publish our subgraph schemas to GraphOS. To do that, we first need to authenticate Rover with GraphOS.

Complete the first two steps of

2. Clone the router project template

For this quickstart, we'll use some Apollo-hosted example services as our subgraphs, and we'll set up the Apollo Router in front of them. The Apollo Router is a high-performance, precompiled Rust executable that acts as the router for a supergraph.

First, let's create a project directory for your router:

1. Open
   this GitHub template
   . It provides out-of-the box configuration for deploying and running the Apollo Router via a Dockerfile.
2. On the template page, click Use this template > Create a new repository to copy the template into a new repository in your GitHub account.
   • If you don't use GitHub, you can instead clone the template directly via the Code menu.
3. Clone your new repository to your local machine.

3. Start the router with Docker

To run the Apollo Router locally, you need a way to build and run containers. Here are some popular options:

• Docker Desktop
• Rancher
• Podman

Try building and running your router container:

docker build -t router .
docker run -it -p4000:4000 router

When you do, you'll get a startup error message like the following:

1
Apollo Router v1.18.0 // (c) Apollo Graph, Inc. // Licensed as ELv2 (https://go.apollo.dev/elv2)
2

3
⚠️  The Apollo Router requires a composed supergraph schema at startup. ⚠️
4

5
👉 DO ONE:
6

7
  * Pass a local schema file with the '--supergraph' option:
8

9
      $ ./router --supergraph <file_path>
10

11
  * Fetch a registered schema from GraphOS by setting
12
    these environment variables:
13

14
      $ APOLLO_KEY="..." APOLLO_GRAPH_REF="..." ./router
15

16
      For details, see the Apollo docs:
17
      https://www.apollographql.com/docs/router/managed-federation/setup
18

19
🔬 TESTING THINGS OUT?
20

21
  1. Download an example supergraph schema with Apollo-hosted subgraphs:
22

23
    $ curl -L https://supergraph.demo.starstuff.dev/ > starstuff.graphql
24

25
  2. Run the Apollo Router in development mode with the supergraph schema:
26

27
    $ ./router --dev --supergraph starstuff.graphql

That's because we aren't currently providing a supergraph schema to the router! We'll fix that soon.

4. Obtain your subgraph schemas

1
extend schema
2
  @link(url: "https://specs.apollo.dev/federation/v2.0",
3
        import: ["@key"])
4

5
type Query {
6
  "The full list of locations presented by the Interplanetary Space Tourism department"
7
  locations: [Location!]!
8
  "The details of a specific location"
9
  location(id: ID!): Location
10
}
11

12
type Location @key(fields: "id"){
13
  id: ID!
14
  "The name of the location"
15
  name: String!
16
  "A short description about the location"
17
  description: String!
18
  "The location's main photo as a URL"
19
  photo: String!
20
}

1
extend schema
2
  @link(url: "https://specs.apollo.dev/federation/v2.0",
3
        import: ["@key"])
4

5
type Query {
6
  "The three latest reviews submitted for FlyBy's locations"
7
  latestReviews: [Review!]!
8
}
9

10
type Mutation {
11
  submitReview(locationReview: LocationReviewInput): SubmitReviewResponse
12
}
13

14
type Location @key(fields: "id") {
15
  id: ID!
16
  "The calculated overall rating based on all reviews"
17
  overallRating: Float
18
  "All submitted reviews about this location"
19
  reviewsForLocation: [Review]!
20
}
21

22
type Review {
23
  id: ID!
24
  "Written text"
25
  comment: String
26
  "A number from 1 - 5 with 1 being lowest and 5 being highest"
27
  rating: Int
28
  "The location the review is about"
29
  location: Location
30
}
31

32
input LocationReviewInput {
33
  "Written text"
34
  comment: String!
35
  "A number from 1 - 5 with 1 being lowest and 5 being highest"
36
  rating: Int!
37
  "Location Id"
38
  locationId: String!
39
}
40

41
type SubmitReviewResponse {
42
  "Similar to HTTP status code, represents the status of the mutation"
43
  code: Int!
44
  "Indicates whether the mutation was successful"
45
  success: Boolean!
46
  "Human-readable message for the UI"
47
  message: String!
48
  "Newly created review"
49
  locationReview: Review
50
}

To compose a supergraph schema for our router, GraphOS needs the following information about each of our subgraphs:

• The subgraph's schema
• The URL of the subgraph's GraphQL endpoint (which must be accessible by the router)

Fortunately, we have all this information! Let's send it to GraphOS.

5. Publish your subgraph schemas

Because we've already configured the Rover CLI, we can now use its subgraph publish command to publish our subgraph schemas to GraphOS.

In

To publish our subgraph schema, we'll first use Rover to introspect the running subgraph, then pass the obtained schema to subgraph publish.

1. Paste the following multi-line command into your terminal, but don't run it—you need to modify it first.

   Bash

   rover subgraph introspect https://flyby-locations-sub.herokuapp.com/ | \
   rover subgraph publish --name locations \
   --routing-url https://flyby-locations-sub.herokuapp.com/ \
   --schema - <GRAPH_REF>

   Copy

2. In your terminal, replace the final value <GRAPH_REF> with the appropriate value for your graph. In the screenshot above, this value is MyGraph-1ncyus@current, but your value will be different.

   What's a graph ref?

   A graph ref uniquely identifies a particular variant of a particular graph in GraphOS. Every graph ref is a string with the following format:

   graph-id@variant-name

   • The value before the @ is your graph's unique ID in GraphOS.
   • The value after the @ is the name of the graph variant you're interacting with.

   Each variant of a graph represents a different environment where that graph runs (such as staging and production). For this quickstart, you can keep the default suggested variant name or change it to anything else you like (for example, quickstart). Just make sure to provide the same graph ref to every command in this quickstart!

   After you've published a schema to a particular variant, that variant's graph ref is always available at the top of its README page:

   

3. Run the modified command.

   • If the command is successful, you'll see output like the following:

     Text

     1
     A new subgraph called 'locations' was created in 'docs-example-graph@main'
     2
     The supergraph schema for 'docs-example-graph@main' was updated, composed from the updated 'locations' subgraph

     Copy

   • If the command fails, make sure you've

     authenticated Rover with GraphOS
     . All Rover commands that interact with GraphOS require a valid API key.

   If you open your graph's details in Studio now, you'll see types and fields from the locations subgraph listed on the Schema page:

   

4. Do the same thing for the reviews subgraph, again substituting your graph ref:

   Bash

   rover subgraph introspect https://flyby-reviews-sub.herokuapp.com/ | \
   rover subgraph publish --name reviews \
   --routing-url https://flyby-reviews-sub.herokuapp.com/ \
   --schema - <GRAPH_REF>

   Copy

   You only need to provide a subgraph's --routing-url the first time you publish that subgraph's schema to a particular variant (unless you need to change that URL later).

   If you refresh the Schema page in Studio, you'll now see types and fields from the reviews subgraph as well.

Every time we publish a subgraph schema, GraphOS automatically composes all our subgraph schemas into a supergraph schema! However, our router isn't yet fetching that schema from Apollo. We'll tackle that next.

6. Connect the router to GraphOS

It's time to enable our router to fetch its supergraph schema from GraphOS. To do that, we need a graph API key that we set as the value of an environment variable.

1. Obtain a graph API key for your Studio graph by following these steps:

   How to obtain a graph API key

   ⚠️ CAUTION

   API keys are secret credentials. Never share them outside your organization or commit them to version control. Delete and replace API keys that you believe are compromised.

   1. Go to

      studio.apollographql.com
      and click the graph you want to obtain an API key for.

   2. If a Publish your Schema dialog appears, copy the protected value that appears after APOLLO_KEY= in the example code block (it begins with service:), and you're all set.

      Otherwise, proceed to the next step.

   3. Open your graph's Settings page and select the API Keys tab. Click Create New Key. Give your key a name, such as Production. This helps you keep track of each API key's use.

      ⓘ NOTE

      If you don't see the API Keys tab, you don't have sufficient permissions for your graph. Only organization members with the Org Admin or Graph Admin role can manage graph API keys.

      Learn more about member roles.

   4. Copy the key's value. For security, you cannot view an API key's value in Studio after creating it.

   If you have an Enterprise plan, set the API key's role according to the following:

   • If your router will use a
     protected variant
     , choose Graph Admin.
   • Otherwise, choose Contributor.

   💡 TIP

   Make sure to copy and paste the API key's value somewhere so you can reference it. For security, API keys are not visible in Studio after creation.

2. Create a file called .env in your Router project and paste in the following (replace <API_KEY> with your graph API key and <GRAPH_REF> with your graph ref):

   Text

   1
   APOLLO_KEY=<API_KEY>
   2
   APOLLO_GRAPH_REF=<GRAPH_REF>

   Copy

   ⚠️ CAUTION

   API keys are secret credentials. Never share them outside your organization or commit them to version control. Delete and replace API keys that you believe are compromised. Make sure always to add .env files to your .gitignore file. The router template project already does this.

3. Paste this command into your terminal and run it:

   Bash

   docker run -it --env-file .env -p4000:4000 router

   Copy

   This time there's no error, and you'll see output similar to the following (timestamps omitted for brevity):

   Click to expand

   Text

   1
   INFO Apollo Router v1.18.0 // (c) Apollo Graph, Inc. // Licensed as ELv2 (https://go.apollo.dev/elv2)
   2
   INFO Anonymous usage data is gathered to inform Apollo product development.  See https://go.apollo.dev/o/privacy for more info.
   3
   INFO Running with *development* mode settings which facilitate development experience (for example, introspection enabled)
   4
   INFO GraphOS Studio usage reporting is enabled. See https://go.apollo.dev/o/data for details
   5
   INFO creating apollo exporter spaceport_endpoint=https://127.0.0.1:62894/
   6
   INFO creating apollo exporter spaceport_endpoint=https://127.0.0.1:62894/
   7
   INFO healthcheck endpoint exposed at http://127.0.0.1:8088/health
   8
   INFO GraphQL endpoint exposed at http://127.0.0.1:4001/ 🚀

   Copy

   By providing an API key to the router, you also automatically enable operation metrics reporting to GraphOS, enabling you visualize your graph's performance.

   Learn more about metrics.

Now that our router is running, we can quickly open our browser to localhost:4000 to explore our composed schema in Apollo Sandbox:

Let's execute some test queries against the supergraph. We'll look at metrics for those test queries in the next step.

7. View operation and field metrics

Because our router is connected to GraphOS, it automatically collects and reports metrics on incoming operations and their fields. You can then visualize those metrics in Studio.

Return to

Within a few minutes, the test queries you executed in the previous step should be represented on this page. The Insights page is vital to monitoring your supergraph's performance across all your clients that query the router.

Learn more about the available metrics in the

Variant pages in Studio

8. Deploy your router and connect clients

Now that our router is running successfully in our development environment, we can deploy it to our preferred platform (AWS, Google Cloud, etc.) so clients can begin querying it!

The exact details for deploying the router depend on which platform you use, but these high-level steps hold true for most platforms:

1. Build the Docker image in CI and push it to a container registry (some providers let you skip this step).

2. Deploy the image to your preferred platform (there are

   additional resources for Kubernetes deployments
   ).

3. Set the APOLLO_KEY and APOLLO_GRAPH_REF environment variables in the router's deployment environment, as we did locally in

   this step
   .
   • Keep in mind that APOLLO_KEY is a secret, so use an appropriate mechanism for storing it in your deployment environment.

4. If your platform expects the router to listen on a particular port, set this port in the router.yaml file included with the template:

   YAML

   router.yaml

   1
   supergraph:
   2
     # The socket address and port to listen on
   3
     listen: 127.0.0.1:4000
   4
     # OR if the port is specified via environment variable
   5
     listen: 127.0.0.1:${env.PORT}

   Copy

   💡 TIP

   Learn more about

   router configuration options

   .

After you successfully deploy your router, it's ready to start receiving client operations! If you have any existing client applications that connect directly to your GraphQL API, you can update their GraphQL endpoint URL to your router's URL.

Similarly, any new client applications should use your router's URL.

Next steps

Nice work! We've registered two subgraph schemas with GraphOS, and we've set up a router that fetches its composed supergraph schema so it can execute operations across subgraphs.

If we now publish changes to one of our subgraph schemas, our running router automatically fetches the corresponding changes to the supergraph schema (assuming composition succeeds).

Next, we'll cover some of the most common and important actions to perform on your new supergraph, including:

• Updating subgraph schemas
• Adding another subgraph
• Setting up schema checks