8 Years of GraphQL: Unraveling the Trade-Offs
summary
Eight years of practice yields concrete trade-offs: choose code-first when reusable patterns (pagination, mutation payloads) and consistent resolver wiring matter; choose SDL-first for clear diffs and tool compatibility. Distributing schemas (Apollo Federation, schema stitching) introduces a schema duality—a registry supergraph versus repo SDLS—and increases both development and operational complexity; a removed union member once broke a Gateway query planner because the planner still expected that type. GraphQL shines for internal APIs with many divergent client needs.
AI-written summary · about
chapters (9)
- 0:00Introduction and speaker intro
- 1:25Eight years of GraphQL evolution
- 4:57Core benefits and GraphQL’s true value
- 7:48Schema-first vs code-first approaches
- 13:32Consistency in large teams
- 15:19Schema composition and stitching
- 17:28Federation trade-offs
- 20:41When to distribute schemas
- 21:23Future of GraphQL and closing
related talks
23mBlueprints of Successful GraphQL Architectures
26mBest Practices for Federated GraphQL: Lessons from Teya
24mA GraphQL Survival Kit
25mThe Power of Strongly Coupled GraphQL Queries for Internal APIs
07mIs GraphQL a trap?
23mGradually Adopt GraphQL Without Writing any Backend Code
20mThe State of GraphQL Federation
27mStranger Graphs - Building Federated Workflows with Shared Components