Making changes to the supergraph

Remember that mockup from the very beginning? We're still missing the right side - the activities!

The activities subgraph

We've already built the API for that activities data:

It has similar field entry points activities and activity(id: ID!). But the Activity type has a bunch more fields!

Adding a subgraph to the supergraph story: the launch process

A launch represents the complete process of making schema updates to any variant of a graph.

Schema checks

Before we publish anything to the schema registry, it's recommended to run GraphOS schema checks. We run these checks using Rover, our CLI tool.

There are two types of schema checks: build checks and operation checks.

Build checks

Build checks validate that a subgraph's schema changes can still compose successfully with other subgraph schemas in the supergraph.

For example, if a new type is added to one subgraph, a composition check determines whether that addition is compatible with the rest of the subgraphs in the supergraph. If it isn't, we need to investigate the error and fix it.

Operation checks

Operation checks validate that a schema's changes won't break any operations that existing clients send to the graph.

For example, let's say a web client regularly sends a GraphQL query to retrieve data for its homepage. If a schema change involves adding a required argument to a field in that query, it might break that client's existing operation! An operation check helps us guard against this potential failure, listing out the affected operations and allowing the team to address them.