This is a summary of a longer piece published on the WunderGraph blog. Read the full article here.
If you've worked on a large federated graph, you've probably lived this: a frontend team needs a new field. The resolver takes an afternoon to write. Getting approval to write it takes three weeks.
The reason isn't technical. Federation's composition model is sound — subgraphs give teams independent ownership, the composition layer produces a unified graph, and consumers get one place to query. The problem is everything that has to happen before implementation can start.
The coordination problem, specifically
Say you need a shippingEligibility field on User, combining data from a fulfillment service and a compliance service. Before anyone writes a resolver, someone has to answer:
- Which subgraph owns User? Which team owns that subgraph?
- Can that team extend User with a type they don't own the data for?
- What does the fulfillment team need to expose, and in what shape?
- Does the compliance team's data have a natural entity key that maps cleanly to User?
- Who approves the field name, the type structure, the nullability decisions?
None of these are hard questions in isolation. But in an organization running 50 or 100 subgraphs, with ownership distributed across many teams, the process of answering them — Slack threads, design docs, platform team review, scheduling across backlogs — is where time goes.
The implementation was never the bottleneck. Alignment was.
Why Federation doesn't solve this
Federation was designed to solve a different problem: how do you scale a GraphQL schema technically across many teams? The answer — distributed subgraph ownership with a composition layer — is a good one for that problem.
But Federation composes bottom-up. Each team builds their subgraph independently. The supergraph is whatever the composition process produces. There's no design artifact that represents what the consumer-facing API should look like before teams start building. The supergraph emerges; it isn't specified.
This means there's no natural place for a frontend team to say "here is what we need" and have that statement drive the work. Instead, they have to reverse-engineer who owns what and negotiate the shape of the API across team boundaries — every time.
What a top-down model looks like
WunderGraph's post argues that the workflow should run in reverse. Start with the consumer's ideal query — what they would ask for if there were no constraints. Design the supergraph to answer it. Then figure out which subgraphs need to change and what each team is responsible for.
In their Fission model, a schema change begins as a supergraph-level proposal. A new type or field is sketched in terms of the consumer contract, before any subgraph assignment happens. The full article walks through the shipping eligibility example step-by-step, including how entity keys get propagated across subgraphs. Tooling then identifies which subgraphs are affected, propagates entity key requirements automatically, and routes the proposal to the right owners for review. Each team approves their slice. Implementation begins with a validated, agreed-upon spec.
The result is that the coordination which currently happens informally — across Slack, Miro boards, and meetings — gets a structured surface. Affected teams are identified automatically rather than through institutional knowledge. Sign-off is tracked rather than assumed.
What this means for teams running large supergraphs
The value of this model scales with graph size. At five subgraphs with one team, informal coordination is fine. At fifty subgraphs with fifteen teams, the absence of a structured design-time workflow is itself a product risk. Changes move slowly not because engineers are slow, but because the process of getting alignment has no tooling support.
Fission is positioned as a design-time complement to Federation's runtime machinery — not a replacement. Query planning and execution stay with Federation. The workflow for deciding what the supergraph should look like, and getting teams aligned on it before implementation begins, is what Fission addresses.
It's also, the post notes, the model that makes most sense as AI agents start contributing to API development. An agent that can query the supergraph for existing capabilities and propose structured changes for missing ones — with a human reviewing before anything ships — fits naturally into this workflow. The coordination layer has to exist for that to work at all.
The full article walks through an example of a schema change. Read it on the WunderGraph blog.
Top comments (0)