A Better Way to do CI For GraphQL
When deploying code, you want to be sure that nothing will blow up when things go live. To prevent downtime, it’s a good practice to use CI (continuous integration) to run tests, checks, and ensure your app is fully ready to hit production. If you’re running GraphQL in production, the last thing you want is a schema change to break things for your users. Here at Apollo, we’ve taken stock of every way schema changes could cause downtime, and we’re delighted to announce a new and improved schema check to ensure your GraphQL layer is evolving smoothly 🎉
Using the Apollo CLI, you can ensure changes made to your schema are backwards compatible by checking it against real production traffic.
We’ve redesigned our schema checks experience to prioritize giving you the most important information. Schema checks help you understand how a change will affect your real-life clients. This release comes with a few long-awaited additions:
- Better visibility: Understand not only which clients are affected, but also how. Schema checks help you determine if an operation won’t run with the new schema.
- Change-level and operation-level overrides: For dealing with more nuanced cases.
- Better UX: A visual update that shows usage of your affected operation and provides valuable forensics.
We’ve also made it possible for teams to configure key settings for schema checks in a central place (see the Check Configurations page in Apollo Studio). Using this central configuration, teams can align on best practices (such as a standard deprecation lifecycle) and share information about deprecated clients and operations.
Want to safely evolve your graph in production? Read the docs on schema checks to learn more and see how to try it out!
Stay in our orbit!
Become an Apollo insider and get first access to new features, best practices, and community events. Oh, and no junk mail. Ever.
Make this article better!
Was this post helpful? Have suggestions? Consider so we can improve it for future readers ✨.