Improving User Experiences with a Nullable Schema
summary
A clear claim: marking fields non-null causes cascading failures when a downstream service (example: a split-out prices API) fails and null bubbling turns every book query into null. The practical fix is client-side control: use Client Controlled Nullability or the required directive to mark per-view requirements, and transform server schemas on the client with graphql-tools/wrap/stitch to produce an incremental nullable schema. Migrate type-by-type, wait for client updates, and prefer nullable defaults so UIs degrade gracefully instead of fully failing.
AI-written summary · about
chapters (7)
- 0:00Introduction to nullability
- 1:15Designing the initial schema
- 3:21Risks of rigid schemas
- 6:36Client-side requirements
- 9:48Managing nulls in queries
- 14:23Incremental migration strategy
- 19:10Conclusion and Q&A
related talks
31mSemantic Nullability - A Path Toward Safe NonNull Fields
32mThe Billion D∅Llar Panel - Nullability in GraphQL
10mUNSET Fields: Contrasting Null and Purposeful Omissions in Server Response
21mHow not to break GraphQL clients?
06mWrite better queries & mutations
23mHandling breaking changes in a GraphQL schema
33mEvolving GraphQL Schemas
49mGraphQL Schema Design — Building Schemas Correctly (version 2)