How to Not Break Your GraphQL Clients
summary
Concrete workflow to stop accidental GraphQL breakage: run schema snapshot tests, upload schemas to a schema registry (Hot Chocolate / Banana Cake Pop / Barista demoed) which diffing blocks publishes and pinpoints the exact queries and fields that break across dev and prod stages, and upload client persisted-query files so the registry can validate every client version. Persisted queries also let the server reject unknown queries for security. Demo shows the registry blocking a breaking publish and reporting two broken queries.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:08GraphQL schema as contract
- 2:10Breaking changes with simple edits
- 3:53Schema snapshot testing
- 5:28Limitations of snapshot testing
- 6:54Categories of GraphQL changes
- 7:55Schema registry in CI pipelines
- 10:02Demo of schema registry
- 13:36Breaking changes are inevitable
- 14:17Client requirements and versions
- 16:02Persistent queries explained
- 17:11Demo of client validation
- 19:42Benefits of persisted queries
- 21:49Q&A: Dynamic schemas and public APIs
- 24:29Q&A: API versioning
- 25:52Q&A: Persisted queries first
- 27:20Q&A: Schema retention
- 28:01Q&A: Client with many parsers
- 29:08Q&A: Field usage tracking
- 31:12Closing and contact
related talks
21mHow not to break GraphQL clients?
29mClosing the Loop: How GraphQL Gives Coding Agents Eyes on What Actually Matters
24mA GraphQL Survival Kit
41mGraphQL: The Good Parts
23mHandling breaking changes in a GraphQL schema
50mDistributed GraphQL APIs: Breaking Down Monoliths & Unlocking Agility for Dev Teams
07mshare how avoid these GraphQL pitfalls
56mDistributed GraphQL APIs