The Case Against __typename
summary
Claim: relying on __typename for client-side type checks breaks forward compatibility, bloats payloads, and fails on nested abstract types. Meta implements is_fulfilled booleans (one per interface/type, always true) and uses them in generated mobile models and Relay-like aliasing to detect implemented interfaces reliably; this reduces __typename queries and fixes rendering bugs in older clients. Caveat: normalized caching still sometimes needs __typename for unique keys; an RFC exists and the approach is deployed internally.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:03What is __typename
- 2:25Problems with __typename
- 5:15Schema evolution issues
- 8:06Forward compatibility limits
- 10:10Nested abstract types
- 12:39Fulfilled fields solution
- 17:36Relay’s @alias directive
- 19:42Normalized caching impact
- 21:49Reducing __typename usage
- 22:29Summary and RFC
related talks
57mDesign Patterns - The Most Common Misconceptions (2 of N)
49mApplied Modern C++: beyond type erasure and visitor pattern
01h 07mDependency Injection Patterns: Efficiency and Usability
31mNothing Generic About It
24mGraphQL Clients
01h 01mComposable C++: Principles and Patterns
41mEnough TMP to write a Variant
51mDesign Patterns: Facts and Misconceptions