Building Distributed GraphQL APIs
summary
Starts with a monolith but designs it to be taken apart, then partitions a single Graph into independent subgraphs (example: accounts + reviews) that compose at build time into a Gateway using hot chocolate Fusion. Composition infers routing and supports zero configuration subscriptions, the node pattern and query plans that batch and reorder fetches to turn hundreds of calls into two. Demo numbers: Netflix scale cited ~130 subgraphs, live latency ~20–30ms dropping to ~6ms with AOT, and composition catches conflicts at build time.
AI-written summary · about
chapters (24)
- 0:00Introduction to GraphQL APIs
- 1:45Why avoid GraphQL monoliths
- 2:30Scaling APIs: data, throughput, developers
- 3:53Microservices vs monoliths
- 5:02BFFs and their limitations
- 7:12GraphQL as a gateway technology
- 9:22Distributed GraphQL benefits
- 10:46Distributed GraphQL for team scalability
- 12:11Schema stitching vs Federation
- 14:20Apollo Federation explained
- 17:13Introducing GraphQL Fusion
- 19:38Demo: Basic GraphQL Fusion setup
- 22:48Demo: Gateway and subgraph composition
- 26:46Demo: Merging overlapping schemas
- 27:31Build pipeline for distributed GraphQL
- 29:00Query plans and optimization
- 36:14Real-time GraphQL subscriptions
- 39:31Zero-config GraphQL Fusion
- 39:51Relay schema pattern
- 44:07Implementing the Node pattern
- 48:56Open source and resources
- 51:40Performance and deployment
- 52:40When to distribute GraphQL
- 55:34Q&A session
related talks
50mDistributed GraphQL APIs: Breaking Down Monoliths & Unlocking Agility for Dev Teams
01h 05mBuilding Distributed GraphQL APIs
56mDistributed GraphQL APIs
30mGraphQL Fusion Rethinking Distributed GraphQL
01h 05mWorkshop: Scaling and Securing API Development with a GraphQL Platform
06mEscape the GraphQL Monolith
08mGraphQL: everything you want in one query
51mWhy GraphQL is Perfect for Microservices