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
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.
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 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 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.
Share your questions and comments about this lesson
Your feedback helps us improve! If you're stuck or confused, let us know and we'll help you out. All comments are public and must follow the Apollo Code of Conduct. Note that comments that have been resolved or addressed may be removed.
You'll need a GitHub account to post below. Don't have one? Post in our Odyssey forum instead.