Apollo Uplink

When using managed federation, your supergraph's router by default regularly polls an endpoint called Apollo Uplink for its latest supergraph schema and other configuration:

If you're using Enterprise features, Uplink also serves your router's license.

To maximize uptime, Uplink is hosted simultaneously at two endpoints, one in GCP and one in AWS:

• GCP: https://uplink.api.apollographql.com/
• AWS: https://aws.uplink.api.apollographql.com/

Default polling behavior

Apollo Router

If you use the Apollo Router with managed federation, by default it polls Uplink every ten seconds. Every time it does so, it cycles through Uplink endpoints in round-robin fashion.

Whenever a poll request times out or otherwise fails (the default timeout is thirty seconds), the router continues polling as usual at the next interval. In the meantime, it continues using its most recent successfully obtained configuration.

@apollo/gateway

If you use the @apollo/gateway library with managed federation, by default your gateway polls Uplink every ten seconds. Every time it does so, it cycles through Uplink endpoints in round-robin fashion.

Whenever a poll request fails, the gateway retries that request (again, using round robin). It continues retrying until a request succeeds, or until reaching the defined maximum number of retries.

Even if a particular poll request fails all of its retries, the gateway continues polling as usual at the next interval (with its own set of retries if needed). In the meantime, the gateway continues using its most recent successfully obtained configuration.

Configuring polling behavior

You can configure the following aspects of your router's Uplink polling behavior:

• The interval at which your router polls (minimum ten seconds)
• The list of Uplink URLs your router uses
• The request timeout for each poll request (Apollo Router only)
  • For @apollo/gateway, this value is always thirty seconds.
• The number of retries performed for a failed poll request (@apollo/gateway only)
  • The Apollo Router does not perform retries for a failed poll request. It continues polling at the next interval.

Apollo Router

You configure Uplink polling for the Apollo Router by providing certain command-line options when running the router executable. These options all start with --apollo-uplink.

See the Apollo Router docs.

@apollo/gateway

Retry limit

You can configure how many times your gateway retries a single failed poll request like so:

1
const { ApolloGateway } = require('@apollo/gateway');
2

3
// ...
4

5
const gateway = new ApolloGateway({
6
  uplinkMaxRetries: 2
7
});

By default, the gateway retries a single poll request a number of times equal to three times the number of Uplink URLs (this is almost always 6 times).

Even if a particular poll request fails all of its retries, the gateway continues polling as usual at the next interval (with its own set of retries if needed). In the meantime, the gateway continues using its most recently obtained configuration.

Poll interval

You can configure the interval at which your gateway polls Apollo Uplink like so:

1
const { ApolloGateway } = require('@apollo/gateway');
2

3
// ...
4

5
const gateway = new ApolloGateway({
6
  pollIntervalInMs: 15000 // 15 seconds
7
});

The pollIntervalInMs option specifies the polling interval in milliseconds. This value must be at least 10000 (which is also the default value).

Uplink URLs (advanced)

You can provide a custom list of URLs for the gateway to use when polling Uplink. You can provide this list either in the ApolloGateway constructor or as an environment variable.

ApolloGateway constructor

Provide a custom list of Uplink URLs to the ApolloGateway constructor like so:

1
const { ApolloGateway } = require('@apollo/gateway');
2

3
// ...
4

5
const gateway = new ApolloGateway({
6
  uplinkEndpoints: [
7
    // Omits AWS endpoint
8
    'https://uplink.api.apollographql.com/'
9
  ]
10
});

This example omits the AWS endpoint, which means it's never polled.

Environment variable

You can provide a comma-separated list of Uplink URLs as the value of the APOLLO_SCHEMA_CONFIG_DELIVERY_ENDPOINT environment variable in your gateway's environment:

1
APOLLO_SCHEMA_CONFIG_DELIVERY_ENDPOINT=https://aws.uplink.api.apollographql.com/,https://uplink.api.apollographql.com/

Schema size limit

Supergraph schemas provided by Uplink cannot exceed 6MB in size. The vast majority of supergraph schemas are well below this limit.

If your supergraph schema does exceed 6MB, you can set up a build status webhook for your graph. Whenever you're notified of a successful supergraph schema composition, your webhook can fetch the latest supergraph schema via the Rover CLI.

Bypassing Uplink

In advanced use cases, you may want your router to use a supergraph schema different than the latest validated schema provided by Uplink. For example, you have different deployment environments for the same graph variant, and you want everything that managed federation provides except for your routers to use supergraph schemas specific to their deployment environment.

For this scenario, you can follow a workflow that, instead of retrieving supergraph schemas from Uplink, uses the GraphOS Platform API to retrieve a supergraph schema for a specific GraphOS launch. The workflow, in summary:

1. When deploying your graphs, publish your subgraphs in a batch using the GraphOS Platform API.
   • The Platform API triggers a launch (and possible downstream launches for contracts) and returns the launch ID (and downstream launch IDs, if necessary).
2. Poll for the launch status, until the launch (and all downstream launches) has completed successfully.
3. Retrieve the supergraph schema of the successful launch by calling the Platform API with the launch ID.
4. Set or "pin" the supergraph schema to your routers by deploying them with the --supergraph or -s option.

For an example with operations calling the Platform API, see a blue-green deployment example.