Shopify's Breadth-First Bet: Rethinking GraphQL Execution
summary
Shopify rewrites GraphQL execution to run breadth-first resolvers instead of depth-first, batching each selection across all objects so five fields over 100 items produce ~5 resolver runs not 500. They build an engine called Cardinal, open-source TypeScript core and a Ruby production engine, and report shaving 4–8 seconds off large queries while seeing up to 120x less GC at ~10k objects; trade-offs include altered error path semantics and result-building bottlenecks that required API and migration work.
AI-written summary · about
chapters (13)
- 0:00Introduction and setup
- 1:02Shopify’s GraphQL challenges
- 3:11Introducing Cardinal engine
- 5:43Depth vs breadth in GraphQL
- 7:30Depth-first traversal problems
- 8:58Breadth-first resolver model
- 10:00Batched resolvers vs data loader
- 12:47GraphQLJS benchmarks
- 14:58Promise overhead in depth-first
- 16:23Garbage collection impact
- 17:47Mechanics of breadth execution
- 21:58Error handling in breadth model
- 23:41Q&A session
