GraphQL Federation Was Built Backwards

This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).

GraphQL Federation's bottom-up composition model creates coordination bottlenecks: the consumer-facing supergraph becomes a side effect of what backend teams independently build, rather than a deliberately designed API. The author argues this inverts GraphQL's original consumer-first philosophy. WunderGraph's Fission addresses this by flipping the model — teams start by designing the ideal consumer-facing supergraph (using 'dream queries'), then Fission decomposes it into subgraph responsibilities, automatically propagating entity keys and routing proposals to the right stakeholders. Fission complements rather than replaces Federation: Federation handles runtime query execution, while Fission handles design-time collaboration and schema evolution workflows.

10m read timeFrom wundergraph.com
Post cover image
Table of contents
The Original Promise of GraphQLHow Federation Broke That PromiseWhy GraphQL Federation Schema Changes Take So LongTop-Down vs Bottom-Up GraphQL API DesignWhat Fission Actually DoesWhy This Matters More Than It SoundsFission Doesn't Replace FederationThe Monolith-to-Microservices ParallelWhat This Looks Like in PracticeLooking AheadWhy Fission ExistsFrequently Asked Questions (FAQ)

Sort: