♻️ Schema evolution

Our app, along with our schema, is intended to evolve over time as we add new features and improve our codebase. To support this healthy schema evolution, we can use the Apollo schema registry.

🤔 What is the schema registry?

At its core, the schema registry is a version control system for our schema. It stores our schema's change history, tracking the types and fields that were added, modified, and removed. The registry powers almost every Apollo feature.

Similar to how we commit and push changes to our codebase to a Git repository, we should push every new version of our schema to the registry. Apollo Server can do that for us automatically on startup, or we can include it as a step in our CI/CD process.

Thanks to the schema registry, we can track variants of the same graph that are deployed in different environments, such as staging and production. We can run schema checks to detect when a potential change might break one of our clients. We can also use the Explorer on a production graph without relying on introspection, so our graph's structure is kept private from unauthorized clients.

As our graph grows, multiple teams might even want to break parts of it into separate subgraphs that they manage independently. The schema registry can take care of tracking all those subgraphs, enabling Apollo to surface potential conflicts between them, and even powering schema composition with Apollo managed federation!

So many cool and powerful features come with the schema registry! We'll focus on only a couple for this course: storing schema change history for a single graph and field usage.