Handling breaking changes in a GraphQL schema
summary
Shows how a breaking change truly behaves by example: replacing user.name with firstName and lastName must be done by add deprecate migrate remove so existing queries keep working. Recommends CI checks with GraphQL Inspector to fail PRs that remove types or change required/optional inputs. Calls out mobile pain: after two releases only about 60% adoption after two weeks so removals can still hit live clients. Gives exact breaking-change cases (removing fields, renaming, type changes, optional↔required inputs) and migration steps.
AI-written summary · about
chapters (8)
- 0:00Handling GraphQL breaking changes
- 1:48What makes changes breaking
- 5:24Safe deprecation approach
- 7:55Mobile apps complicate changes
- 13:35Common breaking patterns
- 15:19Detecting changes with Inspector
- 17:24Summary and best practices
- 18:05Q&A on deprecation
related talks
21mHow not to break GraphQL clients?
32mHow to Not Break Your GraphQL Clients
30mThe Biggest Change To GraphQL Codegen in 10 Years
33mEvolving GraphQL Schemas
48mWinning at Continuous Deployment: The Art of Safe Contract Changes
13mLightning Talk: Breaking up With Inputs (Without Breaking Your Users)
24mBreaking the Interface - API Versioning with REST, JSON and Swagger
24mA GraphQL Survival Kit