Making the right choice: WunderGraph or ApolloOS for your API architecture??

Written by our Founder and CEO...

My name is Jens, and I'm the Founder & CEO of WunderGraph, but most importantly, I'm a Developer - always have been and always will be. At WunderGraph, we're a small but growing team, and I'm still actively involved in developing the product. That's why what I'm sharing with you isn't just from a CEO's perspective - it's from the viewpoint of a developer who's in the trenches every day.

While WunderGraph and Apollo have similar goals, their approaches differ - and understanding their histories can shed some light on that. Let's take a closer look at both.

Apollo, successor to Meteor, the "best way" to build with GraphQL

Geoff Schmidt, the CEO of Apollo describes Apollo as the successor to Meteor.

Apollo began life as the Meteor 2 data system, designed from all of the learnings from Livedata, which ultimately could be summarized as: there needed to be an abstraction layer in between the client and the server, rather than embedding MongoDB queries in the client. --- Geoff Schmidt, CEO Apollo

Meteor ran into the limitations of tightly coupling the client and the server. Interestingly, we can see this pattern repeat itself, with solutions that generated a GraphQL API from the Database, and expose it to the client.

So, the idea behind Apollo is to create an abstraction layer between client and server. Additionally, Apollo introduced the concept of the Supergraph, the idea to implement a Graph in a distributed way. This can also be found in their headline:

The GraphQL developer platform.

It's all about helping companies to build GraphQL APIs.

Should you use Apollo for GraphQL? Or is there another way?

WunderGraph, is a new way to think about APIs, leveraging GraphQL

The history of WunderGraph is different. I've worked in Enterprise Software Development for a while and realised that there's a huge problem with API composition & development. We spent so much time composing APIs of different protocols, transports, and so on.

Early on, I had the idea that it should be possible to query every system using GraphQL, removing the overhead of having to write manual code to mediate protocols and implementations.

While I was working on the solution, a GraphQL Engine to automatically mediate between a GraphQL layer and the underlying systems, I've realized that my thinking was wrong and limiting. We don't need more abstractions. We don't need better ways to build GraphQL APIs. In fact, the goal shouldn't be to build GraphQL APIs. My understanding of APIs was wrong.

While using GraphQL as the language for API composition is promising, it's important to shift away from a "server-full" mindset. This shift can help us create more flexible and scalable solutions that meet the needs of modern development.

Treating APIs as dependencies can transform your development process

Let's try and understand this. What if we treated APIs as depedencies? Let me explain this a bit more in depth.

The traditional, Apollo-way of adding another internal or external API or database to a system is to extend "THE Graph". However, I've realized that the number of APIs is only growing, and so we'd have to continuously extend our Graphs with every new API we'd like to use. There needs to be a better way to build a system that can handle an exponentially growing number of APIs.

We can borrow the solution from existing programming paradigms, it's called "dependency management" or, more well known, "package management". If you need another "package", you can npm install or go get it. The package manager manages the dependencies of you project and helps you to update them.

Now, APIs are not code. You can't just "add an API" to your application. It's a lot more complicated than that... or is it?

GraphQL as the language for API composition

The Apollo-way is to build Subgraphs and compose them into a Supergraph. If an application needs to use multiple APIs, it talks to the Supergraph. That's what I call "API-full".

WunderGraph takes a different approach. We don't build one monolithic Supergraph. We also don't have to adopt GraphQL and Subgraphs all across the organization. In fact, WunderGraph embraces diversity in API styles. WunderGraph can compose APIs of different styles, like REST, GraphQL, Apollo Federation (Subgraphs and Supergraphs), gRPC, Kafka, PostgreSQL, MySQL, MongoDB, etc...

But instead of building a single, monolithic API, WunderGraph allows you to build a unique composition for each application. That's the whole point of "package management".

In an exponentially growing system of APIs, you will eventually run out of resources to connect to "gigantic" Supergraphs. It's the same with npm. You only install the packages you need, otherwise your node_modules folder would grow beyond the limits of your system.

In more technical terms, WunderGraph allows you to compose multiple API dependencies into a single unified Graph with just a few lines of code.

const weather = introspect.graphql({
    apiNamespace: 'weather',
    url: 'https://web.archive.org/web/20230115160917/https://graphql-weather-api.herokuapp.com/',
});

const countries = introspect.graphql({
    apiNamespace: 'countries',
    url: 'https://web.archive.org/web/20230115160917/https://countries.trevorblades.com/',
});

configureWunderGraphApplication({
    apis: [weather, countries],
});

This is how you would create an API composition for your application, where you are combining a weather and a countries API. Then you would define you GraphQL Operations, WunderGraph generates an API Gateway for you that "executes" your API composition.

Should you expose GraphQL APIs?

How we expose APIs is another topic which distinguishes WunderGraph from Apollo. Apollo, by default, exposes your GraphQL APIs over HTTP. You then have to add additional 3rd party libraries to lock your API down, add authentication, authorization, and so on. So, their approach is to give the user a very basic server implementation and leave security to the user.

The WunderGraph approach is to never expose a GraphQL API at all, and manage all aspects, from security to authentication, authorization and caching out of the box. We provide an end-to-end solution that implements OWASP recommendations by default . WunderGraph is locked-down from the beginning, you don't have to add any additional libraries or modules.

WunderGraph does out of the box:

• Input Validation using JSON-Schema
• Injection Prevention / Process Validation (at compile time)
• Query Limiting (Depth), Query Cost Analysis (at compile time)
• Server-side batching and caching
• Timeouts -Access Control protection with RBAC and ABAC
• mitigates batching attacks
• prevents introspection attacks

With Apollo, you're responsible to handle the security of your GraphQL APIs on your own. But should you really be focusing on security, or is this a framework concern, and you should focus on the application itself?

Interestingly, in the beginning, Geoff was hesitant to allow clients to send arbitrary queries to the server.

Similarly, and also to accommodate larger and more complex apps, we would move UI component data dependency specification from the backend (a DDP "publication") into the UI components, by letting the frontend send a query over the wire to the backend. The reason we didn't do this in the first place was security—I thought it would be hard to convince people to use Meteor if the client was sending arbitrary clients to the server. --- Geoff Schmidt, CEO Apollo

It seems that they've dropped these concerns in favour of adoption. But as you will see, doing the right thing security-wise doesn't have to come with a lot of effort.

But let's say you still want to expose a GraphQL API and handle everything on your own. WunderGraph still allows you to expose a GraphQL API, even though we still reccommend against it!

Comparing the WunderGraph Developer Workflow with ApolloOS

To make this work, we've developed the WunderGraph Compiler and Runtime, which takes the API composition and Operations as input, and compiles them into a JSON-RPC API, while also generating a type-safe client for ease of use.

Let's break down the WunderGraph flow:

• Add API dependencies to your project
• Define GraphQL Operations
• WunderGraph generates a JSON-RPC API and a type-safe client
• Deploy Serverless API Gateway alongside your frontend

Now let's compare this flow with Apollo:

• Wrap all "API dependencies" in Subgraph
• Compose the Subgraphs
• Deploy the Supergraph
• Add Apollo client to your Frontend
• Define GraphQL Operations
• Lock down the API, add authentication, authorization, caching, and so on via additional extensions

The development workflow is quite similar, but the WunderGraph Architecture comes with batteries included.

Open Source GraphQL Solutions

While I tried to focus on Architecture and Developer Workflow, there are a few other things I'd like to point out regarding Open Source.

WunderGraph supports Apollo Federation out of the box, not just the Subgraph implementation, but it's actually possible to use WunderGraph as an Apollo Federation Gateway replacement. Our approach to GraphQL doesn't just make Federation a lot more secure, but is also very efficient, as our benchmarks show.

That being said, our Gateway is not just super fast and secure, it's also truly open source. Apollo re-licensed their Federation implementation using the Elastic 2.0 license, while WunderGraph is licensed under the Apache 2.0 license. The GraphQL Engine of WunderGraphis licensed under the MIT license.

This means, no other company is allowed to use Apollo's implementation to provide a hosted GraphQL Gateway, while this is possible with WunderGraph.

In fact, the WunderGraph Federation implementation is a separate package (graphql-go-tools) which is MIT licensed, and it's being commercially used by many other companies. We're even collaborating with some of them actively to maintain and improve it. The Elastic 2.0 license works against such collaborative efforts as really only a single company benefits from it.

The elephant in the room: Pricing

Given the recent changes in pricing from Apollo, I think it's important to highlight the key differences.

Although WunderGraph is open source, we do offer a cloud solution that includes free and paid tiers.

Both WunderGraph Cloud and Apollo have a generious free tier, but there are two major differences between them.

1. In ApolloOS, Introspection queries do count as operations in GraphOS. In WunderGraph, introspection happens at build time and so introspection queries do not count as operations.

2. In the free tier of ApolloOS, you are on shared infrastructure up to 100 TPS. In WunderGraph Cloud each user will get their own dedicated infrastructure.

Paid cloud plans

With ApolloOS pricing starts at $500 per month, while with WunderGraph Cloud your pricing is $25 per month.

Enterprise plans

This biggest advantage of WunderGraph vs ApolloOS is the ability to self-host. Self-hosting is an enterprise feature of ApolloOS. With WunderGraph you are given the ability to self-host from the start for free.

Per Apollo's Documentation:

Self-hosted supergraphs are an enterprise-only feature for organizations with advanced performance or compliance requirements.

Per WunderGraphs Documentation:

WunderGraph is fully open source and can be hosted with your favourite cloud provider

Summary

Do you think in Graphs, or in API dependencies? Should you have a single monolithic Supergraph, or small, lightweight API compositions per application, deployed on "Serverless" API Gateways? Should we adopt "THE GRAPH" for all our APIs, or use GraphQL as a "meta-API" style to compose a variety of API styles? Is it easier to achieve incremental adoption with a GraphQL-only model, or by using GraphQL only virtually, leaving existing systems as is?

Ask yourself which model is best for your organization today, but also allows you to scale in the future. Do you believe in exponential growth of APIs, like we do, or do you think all APIs can be rewritten as Subgraphs.

Our goal is to build the GitHub for APIs. We want to enable new ways of collaboration between API providers and consumers. We believe, the API era has only just begun, and will be fueled by the idea of "API dependencies". GitHub and Open Source brought together developers to build and collaborate on common solutions, allowing for re-usability and composition.

There's barely any npm package without dependencies. You never have to start from scratch, but can build on top of existing packages. With APIs, we're really just starting to enable this kind of collaboration.

The solution is not the Supergraph. It's on-demand composition of any API style, and a model of collaboration that is similar to GitHub, like issues when there's a problem with an API dependency, discussions to propose and discuss API changes, watchers to get notified of API changes, and so on.