UNSET Fields: Contrasting Null and Purposeful Omissions in Server Response
summary
Claims that GraphQL needs a third null state — unset — where the server deliberately does not calculate a field and clients should keep existing values. Concrete cases: WhatsApp delta updates (client sends a timestamp to avoid re-sending a large value) and Instagram server migration (reused REST paths never resolve some image metadata). Current implementations at scale use special error markers (bloats payloads) or unions (break backward compatibility); omitting fields saves bandwidth but contradicts the spec.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 0:44Existing null definitions
- 1:29Gaps in null definitions
- 3:17Migrating from REST to GraphQL
- 5:26Need for unset fields
- 6:09Options for unset representation
- 8:17Leaving fields unset
- 9:01Q&A
related talks
29mFixing the Billion Dollar Mistake Client Controlled Nullability
23mImproving User Experiences with a Nullable Schema
30mWhy GraphQL vs. Why not GraphQL
27mA no nonsense GraphQL and REST comparison
21mStreaming HTTP and GraphQL
25mWhat's next for GraphQL?
29mDamn GraphQL - Defending and Attacking APIs
23mAn Introduction to GraphQL