In-House Schema Registry - The Good the Bad and the Ugly
summary
Explains why rolling a custom schema registry becomes a maintenance and scale problem: a CLI-based Apollo Federation audit runs 170 tests across 40 subgraphs, composition must produce a supergraph artifact, and preventing breaking changes requires static diffs plus runtime usage (persistent operations grouped by deployment) to avoid false positives. At scale ingestion and queries hit billions of operations so storage choice matters — the team moves from Elasticsearch/Postgres to ClickHouse over Elasticsearch/Postgres for fast, compressed analytics. Recommendation: expect heavy engineering, many feature requests, and prefer an existing registry unless full control justifies the cost.
AI-written summary · about
chapters (11)
- 0:00Introduction and speaker background
- 1:07Apollo Federation audit tool
- 3:12Schema registry core concepts
- 8:09Breaking changes detection methods
- 13:51Persistent operations for breaking changes
- 15:38Gateway registry integration
- 18:26Database challenges for schema registry
- 23:06Usage reporting protocol
- 25:53Handling scale and performance
- 28:02Operational challenges
- 30:29Recommendation to use existing solutions
related talks
30mSo you want to distribute your GraphQL schema?
07mshare how avoid these GraphQL pitfalls
29mScaling the Data Access by Leveraging GraphQL Federation for Service to Service Communication
13mLightning Talk: Schema Composition Without Federation
27mHow The Guild is using GraphQL at scale
35mGraphQL Docs: Beyond the Schema
35mGraphQL in the Enterprise
06mEnlist the Help of Your Schema for Caching!