Dataloader 3.0: An Alternative Algorithm to Solve N+1 Problems
summary
Claims that replacing depth-first resolution with a three-step approach — plan depth-first, load breadth-first, render depth-first — removes the need for DataLoader-style concurrency, cutting goroutine/thread usage from about 14 to 3 (or 1 without parallel subfetches) while keeping the same four fetches and similar latency. Describes an implementation in the Cosmo router (WunderGraph), reports ~5x speedup over the previous internal implementation and compares to Apollo Router 1.3, and argues DataLoader trades N+1 for concurrency complexity.
AI-written summary · about
chapters (8)
- 0:00Introduction and game
- 6:51DataLoader 3.0 overview
- 13:18Open Federation initiative
- 19:48Request lifecycle in router
- 26:17Breadth-first execution
- 30:15Takeaways and concurrency
- 33:30Future of distributed GraphQL
- 35:47Q&A session
related talks
30mThe Magic of Dataloader with GraphQL
38mNew HotN+1ness -Hard lessons migrating from REST to GraphQL
25mGrafast: A Declarative Solution To GraphQL's Execution Woes
37mGraphQL The Devil's API
17mAccelerating Collective Communication in Data Parallel Training across Deep Learning...
28mFault Tolerance Training at Pinterest
27mGraphQL on Rails
39mScaling event-driven systems with Node and GraphQL subscriptions