Federation lets consumers see one graph while teams build separate services. But the way teams practice Federation is backwards.
Most teams start from the subgraph: write schema in code, push to the registry, then chase alignment in meetings, tickets, and Slack. The people who use the API come last. You get siloed ownership, unclear who owns what, and frontend developers blocked on questions they can’t answer. Schema registries help after you build. They don’t help you decide what to build, who builds it, or whether it meets the bar.
Start from what consumers need and work down. Define the query. Hub checks the graph, finds the gaps, and sends the work to the right teams—with clear ownership and automated governance built in.
- Explore the full supergraph — Every type, every field, every subgraph, and who owns it.
- Design from what consumers need — Define the query you need; Hub shows what’s missing.
- Propose changes through clear steps — Checks, review by the right owners, and breaking-change checks before you build.
- Coordinate with a full record — Track every proposal, review, and decision.
Hub’s schema engine, Fission, turns proposals into subgraph schemas that plug together (including how entities link and keys). Frontend developers (and AI agents) stay focused on what they need; backend gets clear implementation tasks—without everyone having to master Federation.
Simple explanation. Evolve the schema. Adapt to your workflow. Hub makes the graph and every change easy to understand. You evolve the schema through clear, reviewed steps instead of scrambling to align. Whether you design in Hub first (Schema First) or bring in changes from code (Code First), Hub fits how your team works.
Get started:
