Production readiness checklist

We recommend that you complete this checklist before your supergraph begins handling production traffic from clients.

In Apollo Studio

• Ensure that you've created multiple variants to represent the different environments where your supergraph runs (production, staging, and so on).
  • Optionally, protect your production variant to avoid accidental changes while working in Apollo Studio.
• Ensure that your clients identify themselves by name and version.
  • If you're using an Apollo Client library, you can add a client name and version to the constructor.
    • For example, the React client uses the name and version attributes in the constructor options.
  • If you're using a third-party GraphQL client, set the apollographql-client-name and apollographql-client-version HTTP headers for each request to identify your client.
  • For an example of enforcing client identification in your gateway, see this technote for Client ID enforcement.

Server-side

• For security, disable introspection for all production GraphQL servers.
  • You can continue to view and fetch your GraphQL schemas from Apollo Studio.
• Ensure that you've correctly configured managed federation.
• Ensure that you've integrated rover subgraph check and rover subgraph publish into your CI/CD pipeline.
• If your subgraph servers are listed as compatible with ftv1, ensure that you've enabled federated traces, and that you can view operation metrics as expected in Apollo Studio.
  • Enable fractional trace sampling via fieldLevelInstrumentation to reduce performance hits due to tracing.
• Consider adding caching layers.
  • Apollo Server and the Apollo Router both support automatic persisted queries (APQ) out of the box.
    • If you're using an Apollo Client library, make sure to enable APQ support.
    • If using Apollo Server, ensure that you use a distributed caching system for APQ in production to avoid cache inconsistency across server instances.
    • Optionally use the @cacheControl directive to enable your CDN to cache APQ GET requests using the Cache-Control header.
    • Additionally, you can configure your gateway can send APQ requests to your subgraphs.
      • See the example below.
  • Optionally add full response caching to improve performance.
• Ensure that you've load-tested your graph.
  • Test loads should be representative of your current traffic (both in terms of volume and in terms of the actual operations you execute in the test).
  • To investigate performance issues, use Apollo Studio to identify which operations are performing slowly.
    • Look at resolver execution times to identify slow areas of execution.
    • Whenever possible, avoid making multiple calls to data sources within a single resolver.
    • Understand query plan execution to help understand slow operations and optimize your supergraph to avoid them.

Apollo Gateway APQ example

This example uses both the buildService option and the RemoteGraphQLDataSource class to enable APQ to each subgraph.

1
import {ApolloServer} from '@apollo/server';
2
import {startStandaloneServer} from '@apollo/server/standalone';
3
import {ApolloGateway, RemoteGraphQLDataSource} from '@apollo/gateway';
4
import {readFileSync} from 'fs';
5

6
const gateway = new ApolloGateway({
7
  supergraphSdl: readFileSync('./supergraph.graphql').toString(),
8
  buildService: ({url}) => {
9
    return new RemoteGraphQLDataSource({url, apq: true});
10
  }
11
});
12

13
const server = new ApolloServer({
14
  gateway
15
});
16

17
// Note the top-level await!
18
const {url} = await startStandaloneServer(server);
19
console.log(`🚀  Server ready at ${url}`);