The Billion D∅Llar Panel - Nullability in GraphQL
summary
Panelists outline a concrete path to let servers mark fields as null only on error so clients can opt into a non‑bubbling behavior that preserves usable data and avoids schema breaking changes. Proposal details include using document-level directives or new syntax, introspection to discover semantic nulls, a “don’t blow up mode” for opt‑in behavior, and changes to handle errors per incremental payload so normalized caches (Relay/Apollo) can safely store partial responses.
AI-written summary · about
chapters (15)
- 0:00Introduction to panel
- 1:53Why discuss nullability
- 4:11Default nullability in GraphQL
- 7:46Problems with non-null types
- 9:18Handling errors in GraphQL
- 13:54Partial success in queries
- 15:46Client controlled nullability
- 17:50Semantic nullability explained
- 20:17Audience questions on errors
- 21:44Value of spec proposals
- 24:54Server-side concerns
- 26:17Client detection of features
- 28:55Existing schemas adoption
- 30:23Future directions
- 31:50Closing remarks
related talks
29mFixing the Billion Dollar Mistake Client Controlled Nullability
23mImproving User Experiences with a Nullable Schema
21mHow not to break GraphQL clients?
25mWhat's next for GraphQL?
13mLightning Talk: Breaking up With Inputs (Without Breaking Your Users)
32mFrom learning to thinking in GraphQL
24mPanel discussion hosted by the Apollo team on GraphQL + React
24mGraphQL Directives: An Under Utilized Power at your Fingertips