Production Readiness Checklist

We recommend that you read through this checklist and identify critical features for your team before your supergraph begins handling production traffic.

GraphOS Studio

• Ensure that you've created multiple variants to represent the different environments where your supergraph runs (for example, production, staging, and development).

• Protect your production variant to avoid accidental changes while working in Studio.

GraphOS Router

• Ensure that you've connected your router to your GraphOS supergraph and have enabled GraphOS schema usage reporting.

• For security, turn off introspection for all production routers (by default the router disables introspection, but make sure you are not using --dev mode).

  • You can continue to view and fetch your GraphQL schemas from GraphOS and run operations from GraphOS Studio Explorer.

• Configure the router traffic shaping features:

  • Set request and subgraph level timeouts and rate limits

  • Deduplicate subgraph requests

  • Communicate with subgraphs using APQ

• Enable operation limits to block large and malicious requests

• Configure additional tracing, metrics, and logging through OpenTelemetry or Prometheus

• Enable the operation and query plan distributed cache

• Optionally, enable any other features deemed critical for your deployment of GraphOS Router

Subgraphs/servers

• For security, turn off introspection for all production GraphQL subgraphs.

  • You can continue to view and fetch your GraphQL schemas from GraphOS and run operations from GraphOS Studio Explorer.

• 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 FEDERATED TRACING, 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.

• 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.

• Consider adding caching layers.

  • Apollo Server supports automatic persisted queries (APQ) out of the box.

    • 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.

  • Optionally add full response caching to improve performance.

Clients

• 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 Client ID enforcement.

• Consider adding caching layers.

  • Enable Persisted Queries and/or Automatic Persisted Queries (APQ) support for request-size savings.

  • Enable and configure the client side normalized cache