So you want to distribute your GraphQL schema?
summary
Argues that distributing a GraphQL schema trades developer isolation for heavy operational complexity: schema stitching centralizes links at the gateway and encourages business logic to creep into the API layer, while schema composition or Federation makes service schemas invalid in isolation and forces running the full graph for testing and query planning. Reports GitHub keeps one giant valid schema because it simplifies reviews and ops. Recommends keeping the gateway thin, pushing auth and resolver logic into services, and avoiding splitting the schema too early.
AI-written summary · about
chapters (28)
- 0:00Introduction
- 0:52What is distributed GraphQL
- 5:00Is this the only way going forward
- 5:40Why is GraphQL so popular
- 6:24One use case can fall apart
- 8:49Netflix
- 9:52SoundCloud
- 10:48Facebook
- 11:19GraphQL
- 11:53Schema stitching
- 13:28ID references
- 15:10Relationships
- 16:14Gate
- 16:27What happened
- 18:22What should API getaway do
- 18:37The goal of API getaway
- 18:58Business logic leaks
- 19:28Distributed architecture
- 20:58Schema composition
- 22:36Problems with this approach
- 23:09Testing
- 23:49Query plans
- 24:35Development vs operational complexity
- 25:03Splitting up schemas too early
- 26:02Splitting too early
- 27:11Summary
- 28:55GitHub
- 29:26Playing your schema
related talks
07mshare how avoid these GraphQL pitfalls
51mWhy GraphQL is Perfect for Microservices
27mWhy GraphQL is Perfect For Microservices
50mDistributed GraphQL APIs: Breaking Down Monoliths & Unlocking Agility for Dev Teams
31mDesign Principles of Federated GraphQL
32mIn-House Schema Registry - The Good the Bad and the Ugly
01h 05mWorkshop: Scaling and Securing API Development with a GraphQL Platform
33mPanel: The Composite Schemas Working G...