Today is the first day of the WunderGraph launch week,
it's our first launch week actually. We have a lot of things to share with you, like Open Federation, Cosmo and more...

What excites me the most is that today marks the beginning of a new era for GraphQL. For a very long time, the GraphQL ecosystem has been dominated by a single company. However, this is about to change through two initiatives and the ecosystem that will emerge around them.

The first step is Open Federation, a MIT-Licensed specification to build federated GraphQL APIs.

The goal of Open Federation is to enable the GraphQL ecosystem to build federated GraphQL APIs without having to rely on Apollo's proprietary technology. It's a drop-in replacement for Apollo Federation, it's open source and free to use for everyone.

Most importantly, we're not announcing Open Federation alone.
Open Federation is a joint effort by WunderGraph and The Guild and has already many supporters like Walmart, SAP, Tripadvisor, Grafbase, Escape Tech, Neo4j, TailorTech, Sibipro, Soundtrack Your Brand, Travelpasses, and many more.

The second step is GraphQL Fusion, a specification for composed GraphQL APIs that goes way beyond what Apollo Federation offers, like support for composing not just GraphQL APIs, but also REST(OpenAPI), gRPC, AsyncAPI, and more.

GraphQL Fusion will live under the GraphQL Foundation.
The goal of Fusion is to enable composition of GraphQL APIs with a diverse set of vendors and technologies.

Fusion is a joint effort by ChilliCream, The Guild, Hasura, IBM, Solo.io, AWS AppSync, and WunderGraph.
Instead of every vendor building their own proprietary composition technology, we're building a single open-source specification that everyone can implement,
so that we can all work together to build a better GraphQL ecosystem.

For today, we're focusing on Open Federation, but stay tuned for more information about GraphQL Fusion. You'll definitely hear more about it during the GraphQL Conference by the GraphQL Foundation. We'll be there as well, so make sure to say hi at our booth.

The History of Open Federation

I'm the creator of graphql-go-tools, a GraphQL library for Go that is used by many companies to build GraphQL Gateways and other GraphQL tools.

I've been working on this library for more than 5 years now and it has been a great success. Almost 3 years ago, I started adding support for Apollo Federation to graphql-go-tools. As excited as I was about the idea of Federation, the community was not ready for it yet.
I've added support for Subscriptions years ago,
but demand for it was very low, so my focus shifted to solving other problems.

Fast forward to 2023, suddenly things have changed fundamentally. The GraphQL ecosystem has grown a lot and the demand for Federation has increased significantly.
At the same time, Apollo started closing down their open-source ecosystem with license changes, price increases, and more.

All of this led to a lot of people reaching out to us and asking for help. Some of them, like TailorTech, were even willing to sponsor the development of a Federation v2 compatible Gateway and composition tooling for graphql-go-tools. Others like Walmart helped us a lot with testing or providing GraphQL schemas of their federated Graphs to test our implementation.

But there was a problem we had to overcome first.
What actually is Apollo Federation?

What actually is Apollo Federation?

This might sound like a silly question, but it's actually not. At this point, we should all have some high level understanding of what Federation is. But have you ever looked at the details, like the specification?

Here's the "Specification" of Apollo Federation v2.
It's nine Directives and one Scalar, that's it.

No comments, no explanations, no examples, nothing.
It's everything but a specification and it actually leaves all the important questions unanswered.

For example, how do you actually implement a Federation Gateway?
What is the Gateway supposed to do?
What are the rules to validate a federated GraphQL schema?
How do you actually compose federated GraphQL APIs?
What are the rules to check if two or more subgraphs are compatible?

In comparison, the GraphQL Specification describes in a lot of detail how a GraphQL Server should behave.
It contains numerous examples for validation and execution rules,
as well as descriptions of basic algorithms like how to merge selection sets or how to execute a GraphQL Query.

If you want to understand Apollo Federation in detail,
you have to read a lot of documentation in different places and even then, you'll still have a lot of questions.
You might be able to reverse-engineer the behavior of the Apollo Gateway and Router, but even if you do, there are still some behaviors that seem random and are not documented anywhere.

So we asked ourselves, how can we build tools to compose subgraphs and a Router / Gateway to resolve federated GraphQL Queries without having a proper description of "our understanding" of Federation?

The birth of Open Federation

That's when we decided to start writing down our own understanding of Federation. By writing down all our knowledge, you're able to criticize it and help us improve it.

If you find gaps or mistakes, we can collaborate to find a common understand of what Federation is, how composition works, and how a Gateway should behave.

From that point on, multiple vendors can implement the same specification so you're free to choose the best solution for your use case.

You're not locked into a single vendor anymore, you can switch to a different vendor at any time.
You can even build your own Gateway if you want to. In addition, you can suggest improvements to the specification and actually have an impact on the future of federated GraphQL APIs.

The goals of Open Federation

We don't believe that there's a future for proprietary API Composition solutions.

It's very unlikely that a single vendor with a closed source solution is capable of serving the market with the best possible solution.

We've seen the opposite in the past with OpenAPI.
Before OpenAPI, there were many proprietary custom solutions to describe and manage REST APIs. However, OpenAPI has become the de-facto standard for REST APIs and is supported by many vendors and tools. It's a great success story and has led to a lot of innovation in the REST API space.

We believe that Open Federation can have a similar impact on the GraphQL ecosystem. An open specification will make federated GraphQL much more accessible and attractive to a lot of companies, and therefore will lead to a bigger adoption of GraphQL in general. This in turn will attract more vendors to the GraphQL ecosystem,
which will lead to more innovation and healthy competition.

After all, it's in the best interest of the GraphQL ecosystem to have a diverse set of vendors and technologies.
By standardizing the composition of GraphQL APIs, vendors can focus on their strengths and collaborate with complementing solutions.

The key is Composable Architecture and interoperability.
Different implementations of the specification can focus on different use cases and technologies.

One vendor might focus on a Gateway that is optimized for performance by using Rust or Go, while another vendor might optimize for extensibility, e.g. by writing the Gateway in NodeJS.

At this point, you might be wondering, what's the difference between Open Federation and Apollo Federation?

What's the difference between Open Federation and Apollo Federation?

Apollo Federation is not a complete specification.
It's a set of directives that, if used correctly on a subgraph, will make it compatible with the Apollo Gateway and Router.

Open Federation builds on top of the same directives to specify subgraphs. It's a specification that describes in detail the rules to compose subgraphs,
how federated GraphQL requests should be planned and executed.

Open Federation can be seen as a drop-in replacement for Apollo Federation, just that it's way more specific, open source, and free to use for everyone.

What's the relationship between Open Federation and GraphQL Fusion?

For a lot of use cases, federated GraphQL APIs will be more than enough, and there's no reason not to adopt or use Open Federation.

However, there will be use cases where you want to compose not just federated GraphQL APIs, but also REST APIs, gRPC APIs, AsyncAPI, and more. This is where GraphQL Fusion comes into play.

Conclusion

Federated GraphQL is a mature technology and has been used in production for years. GraphQL Fusion is still in its early stages and will take some time to get to the same level of maturity.

We bet on both technologies and believe that they will complement each other very well. Time will tell if both technologies will live alongside each other or if one will eventually dominate the other. What matters most to us is that we're standardizing the composition of APIs to build a better GraphQL ecosystem.

If you haven't already, make sure to check out Open Federation and have a look at the specification. We're looking forward to your feedback and contributions.