What Food Trucks Taught Me About GraphQL Federation
GraphQL Federation can sound like a heavyweight concept. But if you’ve ever outgrown a single backend, you’ve already felt why it matters.
Instead of diving straight into specs and schema stitching, I want to use a metaphor that helped me think it through: food trucks.
Think of this as a guided tour, one truck at a time, through how APIs grow and where federation fits in.
One Truck, One System
You start small.
One truck. It handles everything: cooking, payment, even delivery. You’ve got full control, no overhead, and a fast turnaround. That’s your monolith.
You don’t need coordination. You don’t need routing. You just serve great food (or great data) from a single place.
Try adding a “super waiter” to this setup — someone standing outside just to hand you orders — and it feels like overkill.
That’s what premature federation looks like. Not wrong, just unnecessary.
Two Trucks, Twice the Trouble
Eventually, growth comes.
You add a second truck to serve a different crowd. Maybe office lunch traffic vs weekend hangouts? The branding matches. The menu overlaps. To the customer, it feels like one business.
But behind the scenes? You’re relaying orders, managing timing, juggling different systems. Each truck rewrites the same burger recipe their own way. Updates get missed. Customers get mixed messages.
So you put a small booth up front to route orders and smooth things over. It helps, at least for now.
Meet Cosmo: Your Federation Layer
Soon, the booth isn’t enough.
New trucks join. A smoothie vendor, a dessert cart, a coffee truck with its own payment system. The complexity outpaces what a simple booth can handle.
Get Stefan 🚀’s stories in your inbox
Join Medium for free to get updates from this writer.
This is where Cosmo steps in.
He’s your super waiter. He knows every truck, every order flow, every timing rule. He doesn’t cook the food, but he makes sure each order gets split, routed, and reassembled into a seamless experience.
To your customer? One order. One tray. One business.
Behind the scenes? A distributed system running like a single restaurant.
Federation in Action
Cosmo doesn’t work alone. For him to do his job, your trucks need to agree on a few things: shared menu names, consistent timing, common order formats.
That’s what makes GraphQL Federation work in the real world: shared types, governance, and coordination. But once that’s in place, federation lets you scale without chaos.
Each team can own its part of the graph, while Cosmo stitches the results into one experience.
From Food Park to Platform
Once Cosmo’s running, you can go beyond food.
Add a checkout truck to handle payments. A delivery truck for mobile orders. A back-office truck for inventory. Each one does its job without needing to know the full picture.
Cosmo keeps it all connected.
The park keeps growing behind the scenes, but the customer experience stays simple.
Why We Built Cosmo
Cosmo isn’t just a metaphor. It’s the open-source federation layer we built at WunderGraph to help real teams manage real complexity.
If your system is starting to feel more like a food park than a single truck, federation isn’t just helpful — it might be essential.
Try Cosmo and see how it makes GraphQL Federation manageable → cosmo.wundergraph.com
Originally published at WunderGraph
This article first appeared on the WunderGraph blog:
A Food Truck Guide to GraphQL Federation
