TL;DR
Host Jens Neuse speaks with Dustin Deus, Jesse Thompson, and Ludwig Bedacht about Cosmo Connect, WunderGraph’s approach to API federation and orchestration. The team walks through first experiments, architectural choices, gRPC adoption, and long-term stability.
Learn more in Jesse's blog post on Cosmo Connect
Prototyping GraphQL-to-gRPC Requests
Every big feature starts small. Ludwig recalled how his first attempt was deliberately simple, aimed at whether GraphQL requests could map cleanly into a gRPC world.
After I was done with that first test, I had my wow moment — okay, it works.
That early test was less about performance and more about confidence. Once it worked, the team knew they had a viable path forward. Instead of theorizing for weeks, they had something concrete to build on.
Choosing gRPC as the Foundation for Cosmo Connect
After the initial experiments, the team had to decide on a foundation. Jens explained why they steered away from niche technologies and chose gRPC as their base.
I thought like if we do like an exotic ecosystem thing, then maybe not many people will adopt it. So I thought, okay, let's go mainstream, let's go gRPC.
This wasn’t just about familiarity. By going with a mainstream protocol, the feature could plug into existing systems without friction. It also meant developers wouldn’t have to learn something entirely new just to adopt what the team was building.
Managing Schema Consistency and Proto Structures
The shift from prototypes to production introduced new challenges. Dustin pointed out that the hardest part wasn’t just making things work, but ensuring the data model remained consistent across systems.
In GraphQL, the order of fields or arguments is not significant. However, in proto the field order is significant, which means if you change a field order in GraphQL, you also need to make it backwards compatible.
Behind that warning was a deeper implementation detail: to keep schemas aligned, the team had to reproduce the same proto structure every time and persist schema information so it could be restored later. Schema mismatches can cascade into failures, so a feature launch only succeeds if the underlying structures are stable enough to support future changes without breaking everything upstream.
Testing for Confidence
With structure in place, the focus turned to testing. Jesse stressed that good tests provide more than coverage—they provide confidence.
If they act within that spec in one test, they will do it in any circumstance more or less.
That reliability let the team move quickly without worrying that each new change might undo past progress. Testing wasn’t just a safety net; it was a way to accelerate development by removing hesitation.
Architecting Cosmo Connect for Long-Term Stability
Looking back, Jesse reflected on how important the initial design was in avoiding missteps later.
So I think we did actually a really good job of architecting it from day one so that we weren't just stepping on our own feet or constantly messing up how we were going to implement this.
That foresight became the quiet success of the project. The team didn’t just ship a new feature. They shipped something built to last. By combining quick prototypes, mainstream choices, careful schema handling, and rigorous testing, they proved that even major launches can stay stable when guided by a clear architectural vision.
This episode was directed by Jacob Javor. Transcript lightly edited for clarity and flow.
