share how avoid these GraphQL pitfalls
summary
Netflix reports dozens of schema updates per day, hundreds of subgraph deployments and billions of GraphQL requests daily, and recommends using Federation while keeping service count aligned with team count (aim for roughly one service per two‑pizza team). Start with a single graph behind a federated gateway, split incrementally, use a schema working group, document pagination and error patterns, accept schema update proposals (sups) via git PRs, and enforce rules with linting so humans handle judgment, not style nitpicks.
AI-written summary · about
chapters (8)
- 0:00Intro
- 1:12Monolithic implementation
- 1:42Michael Pollen
- 3:27Single vs Federation
- 4:10Schema Working Group
- 5:02Documentation
- 5:28Schema update proposals
- 6:06linting
related talks
30mSo you want to distribute your GraphQL schema?
46mMoving to GraphQL
27mWhat if ... How to Achieve GraphQL Domination
29mBig Graphs, Tiny Contexts: Dev Tools for Agents
31mLessons from Scaling GraphQL to Half a Billion Requests per Minute
01h 07mGraphQL: Smooth Schemas and Rough Edges
55mGraphQL from the Ground Up
51mWhy GraphQL is Perfect for Microservices