Q10 of 20 · GraphQL
How do you detect breaking schema changes in a GraphQL API?
GraphQLSeniorgraphqlcontract-testingschemaci-cdsenior
Short answer
Short answer: Snapshot the schema (committed SDL or introspection) and diff it in CI. Removing a field, renaming one, making a nullable field non-null on input, or changing a type are breaking changes for existing clients — catch them before deploy with a schema-diff check.
Detail
GraphQL's single evolving schema is a contract with every client. Unlike REST, you can't version by URL as easily, so schema discipline matters more.
What counts as breaking (for clients querying the API):
- Removing or renaming a field or type
- Changing a field's type
- Making an argument or input field non-null that used to be optional
- Removing an enum value a client might send/receive
What's generally safe (additive):
- Adding a new field, type, or optional argument
- Adding an enum value (with care on inputs)
How to test/catch:
- Commit the schema SDL to the repo as the source of truth.
- Diff in CI: run a schema-diff tool (e.g. graphql-inspector style) comparing the proposed schema against the committed/published one, and fail the build on breaking changes.
- Contract testing: pair this with consumer expectations — what fields do real clients actually request? — so you know whether a "breaking" change actually has consumers.
This is the GraphQL analogue of REST contract testing, and it's where introspection earns its keep.
// WHAT INTERVIEWERS LOOK FOR
A concrete list of what's breaking vs additive, and a CI schema-diff gate as the mechanism — not manual review.