Namespacing Is the Next Frontier of GraphQL Federation
summary
Claims that namespacing, when paired with GraphQL Federation, lets teams safely add fields and extend types without breaking a unified schema, backed by examples like a Stripe invoice extended with an order and a hasShipped field; proposes namespaces as coordination domains rather than per-subgraph prefixes, uses SDL subgraphs, composition rules and declarative reference expressions to map IDs to external types, cites 10 years without namespacing and customers with thousands of APIs, and frames namespacing as a design principle and orchestration-layer idea rather than an off-the-shelf product.
AI-written summary · about
chapters (19)
- 0:00Namespacing in GraphQL
- 2:32GraphQL’s goals and API focus
- 5:43GraphQL as API layer today
- 8:53Why namespacing by service fails
- 12:03Federation and subgraphs as boundaries
- 13:50Schema pitfalls and bottlenecks
- 18:11Bounded contexts and domains
- 20:42Extending types across namespaces
- 22:49Declarative orchestration
- 26:18Clients with schema dependencies
- 27:44GraphQL as orchestration
- 30:13Q&A: Query side
- 31:42Q&A: Contracts vs namespaces
- 32:47Q&A: Schema vs slices
- 35:38Q&A: Schema vs namespaces
- 36:43Q&A: Namespacing by subgraph
- 37:47Q&A: Business logic in queries
- 40:35Q&A: Declarative expressions
- 42:00Q&A: Team autonomy
related talks
22m8 Years of GraphQL: Unraveling the Trade-Offs
31mDesign Principles of Federated GraphQL
17mThe year ahead for GraphQL Federation: Combining APIs for the AI era.
36mGraphQL Federation - The @key to Your Platform API Strategy
51mWhy GraphQL is Perfect for Microservices
20mThe State of GraphQL Federation
07mshare how avoid these GraphQL pitfalls
06mEscape the GraphQL Monolith