How NOT to Build a Supergraph!
summary
Clear naming rules matter: PascalCase for types, camelCase for fields, SCREAMING_SNAKE_CASE for enum values; return linked objects instead of only IDs to avoid client-side waterfalls; always paginate lists and keep a consistent pagination shape; prefer use deprecation not versions to evolve fields without creating multiple endpoints; don’t over- or under-federate—avoid thousands of tiny subgraphs or a permanent single-subgraph router; instrument router and subgraph-level metrics, check GraphQL error objects in load tests, run composition/operation checks and schema linting before production.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:00Schema
- 2:45Return the Thing
- 4:34Pagination
- 5:57Deprecation
- 9:28Federation
- 12:44Entities
- 14:37Observability
- 17:08Load Testing
- 19:32Testing
related talks
23mBlueprints of Successful GraphQL Architectures
22m8 Years of GraphQL: Unraveling the Trade-Offs
24mA GraphQL Survival Kit
07mIs GraphQL a trap?
01h 17mSafely Evolve Your (Federated) GraphQL Schema with GraphQL Hive
21mSafely Merging Subgraphs in a Distributed World
26mThe Easy Way and the Hard Way: Blue-green GraphQL Deployments
07mExperience-Oriented Graphs with Batching