Introducing Fission: A New Way to Design Federated APIs | WunderGraph Webinar - WunderGraph

Chapters

0:00 Intro
0:47 WunderGraph's Federation Stack
3:05 Question 1: Monoliths or Microservices?
4:13 Question 2: Scaling with Microservices?
5:27 The API Design Gap
7:16 How API Design Currently Works
8:28 Yelp: The Dream Query
9:41 Our Fission Algorithm
11:20 Demo: Welcome to the Hub Canvas
13:02 Demo: UI Mockup and Operation Builder
15:03 Demo: Add New Fields
16:30 Demo: Governance
17:33 Demo: Create Threads
18:11 Demo: Visualize your Graph
19:14 Demo: Assign Fields to Subgraphs
19:55 Demo: Proposals and Schema Checks
21:05 Demo: Create a New Microservice
22:30 Payoffs/Benefits
23:10 Get a 1-on-1 Walkthrough

Want to learn more?

Learn how Fission applies to your specific use case.

Schedule a Walkthrough

Speakers

Jens Neuse

CEO & Co-Founder at WunderGraph

Nithin Kumar B

Founding Engineer at WunderGraph

About This Webinar

In this session we introduce Fission, a new approach to API design, governance, and collaboration at scale. The Fission algorithm is a defining characteristic of WunderGraph Hub, enabling teams to design APIs from requirements and automatically derive composable subgraphs. Fission allows developers to work with their supergraph as if it's a monolith, while still being able to implement it in a federated way.

Fission allows developers to define their ideal supergraph starting from a consumer-facing use case, deriving the ideal queries, and then distributing the implementation across one or more subgraphs. It's a paradigm shift allowing teams to create better APIs by focusing on the requirements and not starting with the backend implementation.

Key Topics Covered

The API design gap between monoliths and microservices
Designing APIs from dream queries
The Fission algorithm and how it works
Visual schema design and collaboration in Hub
Governance, ownership, and schema checks
Automatically deriving subgraphs from use cases

Who Should Watch

This webinar is ideal for:

Platform and infrastructure engineers
API and GraphQL architects
Backend and frontend engineers working with Federation
Teams struggling with schema ownership and governance
Organizations scaling APIs across multiple teams

Additional Resources

Frequently Asked Questions (FAQ)

What will I learn from this webinar?

You'll learn how to design federated APIs starting from real client use cases, how the Fission algorithm derives composable subgraphs, and how WunderGraph Hub enables collaboration, governance, and safe schema evolution at scale.

What is the Fission algorithm?

Fission is an algorithm that takes a consumer-facing "supergraph" and a set of data ownership and dependency rules, and automatically derives the required subgraph schemas. Instead of designing services first and composing them later, Fission allows teams to design APIs from use cases and let the system generate composable microservice schemas.

How does Fission differ from traditional GraphQL Federation workflows?

Traditional Federation starts with subgraphs and composes them into an API. Fission flips this model by starting from the ideal client query (the "dream query") and working backwards to determine how data should be split across services, removing much of the manual coordination and guesswork.

Do I need deep GraphQL Federation knowledge to use Fission?

No. Fission abstracts away Federation-specific concerns such as entity keys, cross-service dependencies, and composition mechanics, making it possible for frontend engineers, designers, and non-Federation experts to contribute safely to API design.

Can Fission be used to create or evolve microservices automatically?

Although Fission abstracts away many of the details of GraphQL Federation, it still requires the user to create fields or entities and assign them to subgraphs. That said, Fission is a huge step forward to automating the steps from requirements to production-ready APIs. Once coding agents come into play, they'll be able to interact with the Fission algorithm on their own to evolve APIs on behalf of the user, e.g. by taking a Jira ticket and automatically creating missing fields and subgraphs.