GraphQL Federation composes the supergraph from subgraphs. But the consumer-facing API should be the starting point, not a side effect. Fission flips the model: design the API you want, then decompose it into subgraph responsibilities.

Wundergraph is a blog or publication focused on GraphQL, a query language and runtime for APIs. Through tutorials, guides, and case studies, Wundergraph explores various aspects of GraphQL development, including schema design, query optimization, and integration with frontend frameworks. Developers can learn how to leverage GraphQL to build efficient and flexible APIs that meet the needs of modern web and mobile applications.

WunderGraph

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.

GraphQL Federation Was Built Backwards

Why GraphQL Federation Schema Changes Take So Long