The Easy Way and the Hard Way: Blue-green GraphQL Deployments
summary
Describes a blue‑green GraphQL deployment that stores each composed supergraph as an OCI image layer so routers pin digests and shift traffic by moving tags, enabling an instant rollback without waiting for a redeploy. Uses OCI distribution to keep immutable schema artifacts, runs a 10% canary by assigning 10% of router fleet to a canary tag, watches resolver latency and error rate, and logs tag+digest so engineers can always reconstruct what was live; requires automation and strict backwards compatibility.
AI-written summary · about
chapters (16)
- 0:00Introduction to talk
- 0:42Blue-green deployments explained
- 3:51Why deployment safety matters
- 5:35Risks of GraphQL schema changes
- 7:00Example of risky schema change
- 8:23Two-graph canary deployments
- 9:05Ideal deployment requirements
- 10:11OCI distribution for schemas
- 12:37How schema updates work
- 14:46Automating rollouts and rollbacks
- 15:47Router fleet hot reloading
- 17:51Deployment-based blue-green
- 20:17Why OCI pattern works well
- 21:40Backwards compatibility importance
- 22:21Key takeaways summary
- 22:42Q&A session
related talks
35mReliable Supergraph management with the Apollo GraphOS Operator & Artifacts
20mA Developers Guide to a Blue-Green Deployment Using Kubernetes
23mBlueprints of Successful GraphQL Architectures
46mBlue-green Deployments, A/B Testing, and Canary Releases on Kubernetes
01h 17mSafely Evolve Your (Federated) GraphQL Schema with GraphQL Hive
22m8 Years of GraphQL: Unraveling the Trade-Offs
34mDeploying Without Crying: Deployment Strategies for Peaceful Nights
31mBuild and Deploy Cloud Native (OCI) Artifacts, the GitOps Way