Apollo Studio is an analytics suite that can be used for GraphQL APIs.
You'll need to create an account and an organisation.
If the organisation is already created, get someone to add you to it.
Our organisation is currently here: https://studio.apollographql.com/graph/Proposals-4xf9j
I believe the free plan has a membership limit, so we may need to be careful how many people we add.
To connect a GraphQL instance to Apollo Studio we just need to provide a few settings in environment variables. These currently are:
APOLLO_KEY
- A unique secret that authenticates our instances as belonging to our organisation
APOLLO_GRAPH_ID
- An identifier for our graph
APOLLO_GRAPH_VARIANT
- The name for an instance of a graph. eg dev
, current
APOLLO_SCHEMA_REPORTING
- Boolean for whether to report the graph's schema. Since we use some federated graph features, and federation is not as simple to configure with Studio, this should be set to false.
To comply with our privacy policy and ensure we’re keeping data secure, we don’t want to send any potentially sensitive data to Apollo Studio. For most cases, this isn’t a problem with the default settings. (Seehttps://www.apollographql.com/docs/studio/data-privacy/) However, we have noticed that error logs can sometimes contain full details of SOAP requests to the user office web service, including personal details and API keys. To be safe we’ve configured the app to censor any error messages that get shared with Apollo Studio, using the ApolloServerPluginUsageReporting
This plugin and the Studio reporting operate on a copy of the error, so the original messages will still be returned by the API.
Since we’re on a free Apollo Studio plan, we can’t see the results of this error censoring in the web UI, but if we’re modifying the config or censoring code, the debugPrintReports argument can be used to print the modified errors to console.
Apollo Studio is configured to send daily usage reports to the #user-office-daily-reports slack channel.