Apollo Federation vs Hasura vs WunderGraph: API Gateway Patterns for Headless Commerce (2026)

The moment you go headless, your storefront stops talking to one platform and starts talking to a fleet. Shopify Plus owns cart, checkout, and orders. A search engine owns product discovery. A CMS owns editorial content. Then come reviews, inventory availability, loyalty balances, and a recommendation service, each with its own API, its own auth, and its own idea of what a product is. The frontend team can either wire up all of those calls by hand in the storefront, which turns every page into a waterfall of fetches and couples the UI to every backend, or it can put a gateway in the middle that presents one graph and hides the fleet. This post is about the three gateways teams actually reach for, and the fact that they are not the same kind of tool.

Apollo Federation, Hasura, and WunderGraph Cosmo all end up serving a single GraphQL endpoint to your storefront, but they get there from different starting assumptions. One federates existing GraphQL services. One generates a GraphQL API on top of your databases. One is an open source federation platform built to replace the managed control plane. Choosing by the endpoint they share is how teams end up with the wrong tool. Choose by the problem you actually have.

The Three Models At A Glance

Gateway	Core model	Best when	Licensing and cost	Operational profile
Apollo Federation, Apollo Router	Federates existing subgraphs into one supergraph	Multiple teams own GraphQL services, you want the reference spec	Router is open source, GraphOS control plane and enterprise features are paid	Managed control plane, self hosted or managed router
WunderGraph Cosmo	Open source federation platform, drop in for GraphOS	You want federation without the managed pricing, on your own infra	Apache 2.0, fully self hostable, no per seat lock in	Self host router and registry, or hybrid with managed control plane
Hasura	Generates GraphQL over databases and services	Your problem is exposing databases and custom data as GraphQL fast	Open source engine, paid cloud and enterprise tiers	Runs next to your data sources, connectors for federation

The table's real message is in the middle column. Apollo and Cosmo are federation tools: they assume you already have GraphQL services and you want to compose them into one graph. Hasura is a generation tool: it assumes you have databases and custom logic and you want a GraphQL API over them without writing resolvers. A headless commerce stack often needs both jobs, which is why teams get confused about which one to pick. The question is which job is your bottleneck.

Apollo Federation: The Reference Standard, With A Bill

Apollo defined the Federation specification, and the Apollo Router, written in Rust, is the fastest and most feature complete implementation of it. If your architecture is genuinely federated, meaning separate teams own separate GraphQL subgraphs for catalog, content, and customer, and each publishes its slice of the schema, Apollo is the path of least resistance and the one every GraphQL engineer already knows. The supergraph composes cleanly, the tooling is mature, and the ecosystem of examples is deep.

The catch is commercial and you should price it before you commit. The Router itself is open source, but the parts that make federation operable at scale, the GraphOS schema registry, persisted queries, JWT authentication, and response caching, sit behind the paid GraphOS plan. For a large storefront serving heavy traffic, the usage based pricing on the managed control plane can become a meaningful line item, and the enterprise features you want in production are exactly the ones on the far side of the paywall. Apollo is the right call when you value the reference implementation and the ecosystem enough to pay for the control plane, and when the federation is real rather than aspirational. If you have one team and three services, you are buying a distributed systems tool to solve a problem you do not have yet.

WunderGraph Cosmo: Federation Without The Toll Booth

Cosmo is the answer to the Apollo pricing question. It is a fully open source federation platform under the Apache 2.0 license, built to be a drop in replacement for Apollo GraphOS, and it includes the pieces Apollo charges for: a schema registry, composition checks, analytics, tracing, and a fast router. The router is written in Go on top of graphql-go-tools, supports Federation V1 and V2, and handles native subscriptions and JWT auth without a paid tier gating them. You can self host the whole thing in Docker or Kubernetes, or run a hybrid where you self host the router for data locality and let WunderGraph run the control plane.

For a headless commerce team that has committed to federation and is cost sensitive at scale, Cosmo is the pragmatic choice, because it gives you the same architecture as Apollo with the operational levers in your own hands and no per seat or usage meter running on the critical path. The trade you are accepting is ownership. You run the registry and the router, you own the upgrades, and the ecosystem, while healthy, is smaller than Apollo's, so there are fewer copy and paste answers when something goes sideways. That is the right trade for a team with the platform engineering capacity to run its own gateway and the traffic to make the licensing difference matter. It is the wrong trade for a small team that would rather pay to make the problem someone else's.

Hasura: The Wrong Question If You Only Have GraphQL Services

Hasura is the tool teams reach for when the real problem is not federating existing GraphQL services but exposing data that has no GraphQL API yet. Point Hasura at a Postgres database, a set of custom microservices, or your own product and inventory tables, and it generates a GraphQL API over them, with filtering, pagination, and relationships, without you writing resolvers. For a commerce stack that keeps custom data outside the commerce platform, a bespoke inventory system, a pricing engine, a customer data store, Hasura turns those into a queryable graph in an afternoon.

Where Hasura stops being the answer is pure federation of services that are already GraphQL. Its strength is the database to GraphQL generation, and while it has grown connectors and federation capabilities, reaching for it primarily to compose existing subgraphs is using it against the grain. The clean way to think about a real stack is that Hasura and a federation router are complementary rather than competing. Hasura exposes your custom data sources as a subgraph, and Apollo or Cosmo federates that subgraph alongside the Shopify catalog and the CMS content into the single graph your storefront queries. If your bottleneck is that half your data has no API, start with Hasura. If your bottleneck is that you have six APIs and one frontend, start with a federation router.

When A Gateway Is The Wrong Answer

The most expensive mistake in this space is adopting federation before you need it. Federation is a solution to an organizational problem, many teams independently owning many subgraphs, as much as a technical one. If you are a single team building a single storefront against three or four backends, a backend for frontend, a thin server layer that calls the underlying APIs and shapes exactly the responses your pages need, is simpler, cheaper, and easier to reason about than a supergraph. It is the same principle that governs whether you reach for a heavyweight composable platform or stay on a monolith, which we worked through in the commercetools versus Shopify Plus breakdown.

A backend for frontend also plays naturally with the rendering framework, since the same server that renders the page can own the data fetching, a pattern that fits the architecture we compared in the Hydrogen versus Next.js commerce piece. Reach for a federation router when the graph is genuinely shared across teams, when the number of data sources has grown past what a hand written BFF can maintain, or when you need a schema registry to coordinate breaking changes across services. Until then the gateway is overhead that buys you nothing but a distributed system to operate.

When This Applies To Your Stack

Choose the gateway by the shape of your bottleneck. If multiple teams own GraphQL subgraphs and you want the reference implementation and are willing to pay for the control plane, Apollo Federation is the standard. If you want the same federation architecture on your own infrastructure without the managed pricing, WunderGraph Cosmo is the open source path, at the cost of running it yourself. If your problem is that custom data, inventory, pricing, customer records, has no GraphQL API at all, Hasura generates one and then feeds a federation router as a subgraph. And if you are one team against a handful of backends, skip federation and write a backend for frontend, because the CMS and search layers that a real storefront composes, the ones we covered in the headless CMS comparison, rarely justify a supergraph on their own.

If your team is designing the API layer for a headless storefront and wants the gateway choice, the subgraph boundaries, and the caching strategy designed against real traffic and a real org chart rather than a diagram, Contra Collective builds headless commerce and platform integration for enterprise brands. The gateway that is right for a ten team platform is wrong for a one team storefront, and the cost of picking the heavy tool early is a distributed system you have to run before you have the problem it solves.

FAQ

What does an API gateway do in a headless commerce stack? It sits between the storefront and the backend services, Shopify, search, CMS, reviews, inventory, and presents them as one API instead of many. The frontend queries a single graph, and the gateway routes each field to the right service, which removes fetch waterfalls from the pages and decouples the UI from every individual backend.

Is WunderGraph Cosmo a real replacement for Apollo GraphOS? Yes, for the federation use case. Cosmo is Apache 2.0 licensed and includes a schema registry, composition checks, router, analytics, and tracing, which are the pieces Apollo charges for in GraphOS. The trade is that you self host and own the operations, and the ecosystem is smaller than Apollo's, so it suits teams with platform engineering capacity.

Should I use Hasura or Apollo for headless commerce? They solve different problems and often work together. Hasura generates a GraphQL API over databases and custom services, so use it when your data has no GraphQL layer yet. Apollo federates existing GraphQL subgraphs into one supergraph, so use it to compose services that already speak GraphQL. A common pattern is Hasura exposing custom data as a subgraph that Apollo or Cosmo then federates.

When should I skip a GraphQL gateway entirely? When you are a single team building a single storefront against a few backends. A backend for frontend, a thin server that calls the underlying APIs and shapes page specific responses, is simpler and cheaper than federation. Federation earns its place when many teams own many subgraphs or the number of data sources outgrows a hand written layer.

Does a federation gateway slow down a storefront? A well configured router adds minimal latency and usually reduces total page latency by replacing multiple frontend round trips with one query it resolves in parallel. The risk is an unoptimized supergraph that fans out to slow subgraphs without caching, so response caching and careful subgraph design matter more than the router choice for real world speed.