State of Federation 2026

Jens Neuse
CEO & Co-Founder at WunderGraph
April 4, 2026 · 12min read
Edited on May 21, 2026 by Brendan Bondurant

TL;DR

Fission inverts the usual GraphQL Federation workflow. Instead of composing subgraphs into a supergraph, you design the supergraph first and Fission derives subgraph specs, handling entity keys, directives, and validation automatically.

What is the Fission algorithm?

Fission is a stateful schema graph engine for GraphQL Federation that keeps the consumer-facing supergraph and underlying subgraphs in sync. Architects can design the supergraph first, then use Fission to decompose that design into subgraph specifications with federation keys, directives, dependency propagation, and validation safeguards.

Designing and evolving schemas in GraphQL Federation is hard, especially when many teams and subgraphs are involved.

In a previous post, I argued that Federation's composition model is backwards. It builds the supergraph from the bottom up when it should be designed from the top down.

This post is a technical deep dive into how the Fission algorithm actually does that.

The Problem Fission Solves in GraphQL Federation

To understand Fission, first you need to understand what makes schema changes expensive in Federation.

Consider a federated graph with three subgraphs:

Subgraph: Users

# Subgraph: Users
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}

type Query {
  user(id: ID!): User
  users: [User!]!
}

Subgraph: Orders

# Subgraph: Orders
type User @key(fields: "id") {
  id: ID!
  orders: [Order!]!
}

type Order @key(fields: "id") {
  id: ID!
  total: Float!
  status: OrderStatus!
  createdAt: DateTime!
}

enum OrderStatus {
  PENDING
  SHIPPED
  DELIVERED
}

Subgraph: Products

# Subgraph: Products
type Order @key(fields: "id") {
  id: ID!
  items: [OrderItem!]!
}

type OrderItem {
  product: Product!
  quantity: Int!
}

type Product @key(fields: "id") {
  id: ID!
  name: String!
  price: Float!
}

Composition produces a supergraph where you can query:

In the traditional workflow, the frontend team has to figure out:

• shipping should be a field on Order, but which subgraph owns Order?
• Both the Orders subgraph and the Products subgraph define Order as an entity.
• carrier and trackingNumber come from the shipping provider.
• estimatedDelivery might come from logistics.
• currentLocation requires real-time tracking data.
• Should this be a new subgraph? An extension of Orders? Both?

Fission automates the hardest parts of this process.

What the Fission Algorithm Is

Fission is a stateful schema graph engine, an in-memory system that maintains two synchronized views of your federated graph at all times:

1. The supergraph view — the unified, consumer-facing schema.
2. The subgraph views — one per service, representing what each team is responsible for implementing.

These two views are kept in sync. When you make a change to either one, Fission will automatically propagate the consequences: renaming a type cascades to every subgraph and every field reference. Adding a type to a subgraph pulls in all its transitive dependencies. Entity @key directives propagate automatically. @shareable directives are added bidirectionally when fields exist in multiple subgraphs.

Every edit follows the same pattern: validate first, mutate second, update indexes, and return a structured result. If validation fails, no state changes happen. This ensures you never have a half-applied edit.

The key insight is the synchronization contract:

The supergraph view represents the union of all subgraph views, plus any types and fields not yet assigned to a subgraph.

This means the architect can design the complete API shape first and then decide how to distribute the implementation across subgraphs.

Fission and traditional GraphQL Federation workflows

How the Fission Algorithm Works in Practice

Let's walk through the shipping example step by step.

Step 1: Design on the Supergraph

The architect adds the new types and fields directly on the supergraph:

At this point, ShippingInfo exists in the supergraph but isn't assigned to any subgraph yet. The shipping field on Order is defined but no team is responsible for implementing it. The supergraph is the API you want.

Step 2: Assign to Subgraphs

The architect assigns the new type to an existing subgraph, or if necessary, creates a new one.

When this happens, Fission automatically does several things:

• Transitive dependency propagation:ShippingInfo references String, DateTime, and Boolean.
• Entity key propagation:Order is an entity with @key(fields: "id") in the Orders and Products subgraphs.
• Shareable propagation: If the shipping field ends up defined in multiple subgraphs, @shareable is added bidirectionally.

Step 3: Continuous Validation

Every edit is validated before it's applied.

Fission enforces a comprehensive set of invariants:

• Reference integrity: you cannot remove a type that's still referenced by other fields.
• Last-child protection: you cannot remove the last field from a type that's still referenced elsewhere.
• Key field validity: you cannot rename or change a key field's type.
• Type-kind compatibility: maintain consistent types across subgraphs.
• Interface consistency: if a type implements an interface, it must have all the interface's fields with compatible types.

If any validation fails, the edit is rejected and the state remains unchanged.

A Multi‑Team GraphQL Federation Example

Let's trace through a more complex scenario to see how these steps work together.

Starting state:

The architect adds all new types and fields to the supergraph:

• Product.inventory: InventoryInfo!
• ShippingInfo with carrier, trackingNumber, estimatedDelivery
• PaymentInfo with method, last4, receiptUrl
• New root field: Query.order(id: ID!): Order

Step 2: Assign to subgraphs

• Product.inventory | New Inventory subgraph | Automatically adds key fields. | | ShippingInfo
• Order.shipping | New Shipping subgraph | Adds entity keys. | | PaymentInfo
• Order.payment | New Payments subgraph | Automatically resolves dependencies. | | Query.order | Orders subgraph | Orders already owns the entity. |

From Supergraph Design to Subgraph Specs

Fission can render valid GraphQL SDL from structured state. This means the output reflects every cascading update, renamed field, and propagated directive.

Supergraph Preview

Fission can also render the full supergraph SDL at any time, ensuring the integrity of the API.

Design Decisions Behind Fission

A few architectural choices in Fission to explain:

• Supergraph as the source of truth.
• Automates consequences, not decisions.
• Validate first, mutate second.
• Federation directives as structured state.
• Tracks the full lifecycle.

The Bigger Picture for GraphQL Platform Teams

Fission is the algorithmic counterpart to Hub's collaboration model.

Together, they enable a coherent design and distributed implementation, allowing teams to function effectively within a federated architecture.

When to use Fission for GraphQL Federation

Frequently Asked Questions (FAQ)

What is the Fission algorithm?
Fission is a stateful schema graph engine that maintains two synchronized views of a federated GraphQL schema.

Does Fission replace the Federation composition process?
No. Fission operates at design time, while Federation composition operates at build time.

Can Fission handle existing federated graphs?
Yes. Fission can import existing federated graphs and decompose proposed changes.

How does Fission handle subgraph assignment for new fields?
The architect decides which subgraph should own a new field, and Fission automates the rest.