<article><p>Are you looking for an open source alternative to Apollo GraphOS / Federation? Cosmo is a drop-in replacement. You can 100% self-host Cosmo, e.g. for compliance reasons, or use our managed Cloud.</p><p>My name is Jens, and I'm the Founder &amp; 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.</p><p>While WunderGraph and Hasura have similar goals, their approaches differ - and understanding their histories can shed some light on that. Let's take a closer look at both.</p><h2>A typical development workflow these days</h2><ol><li>scaffold a new project</li><li>make a few commits</li><li>push to a remote repository</li><li>hook up a CI/CD pipeline</li><li>deploy to production</li></ol><p>Next, you start iterating on the product. Modern Serverless platforms like Vercel allow you to deploy previews for each Pull Request. The flow looks like this:</p><p>1.create a new branch 2.make a few commits 3.push to the remote repository 4.open a Pull request 5.preview gets deployed automatically 6.your colleagues can preview the changes 7.when you merge the Pull request, the preview gets deployed to production</p><h2>How Hasura breaks this flow</h2><p>For me, the described flow above is the holy grail of fast iteration. So far, our application was stateless, which we're now about to change. Let's add Hasura to the stack and see how the flow changes.</p><ol><li>scaffold a new project</li><li>start Hasura locally</li><li>start a local database</li><li>Use the Hasura Dashboard to configure the database and API</li><li>Hasura is now working and can be integrated into your application</li><li>make a few commits</li><li>push to the remote repository</li><li>deploy a production database</li><li>deploy a production Hasura instance 10.use the Hasura Dashboard to configure the production database and API 11.deploy the application to production</li></ol><p>There's something inherently wrong with the above workflow. The frontend application is built using the Serverless paradigm, while Hasura is a &quot;Serverfull&quot; solution.</p><p>Even worse, the primary option to configure Hasura is through the user interface. I'm aware that there are ways to configure Hasura through APIs, export and import configurations, and synchronize environments, but it's simply not serverless, and it's definitely designed for use with the Dashboard.</p><p>I know that some developers prefer to have a Dashboard and configure their APIs with point-and-click tools. However, as you scale your applications, you'll always want to configure environments through code. It's more predictable, it's repeatable, you can re-use code, and because you're putting this code into git, you get versioning and rollbacks for free. Finally, this code can live in the same repository as your application code, making the whole workflow a lot easier.</p><p>Things that can go wrong with the above workflow are mainly that you local environment diverges from the production environment, during deployments you forget to synchronize a change, and it might be hard to get the timing right when you have to deploy database migrations.</p><p>Next, let's look at the workflow for continuous development:</p><ol><li>create a new branch</li><li>make changes to the local database</li><li>make change to the local Hasura instance</li><li>integrate the changes into the application</li><li>deploy a staging database</li><li>deploy a staging Hasura instance</li><li>configure both staging database and Hasura with the Dashboard</li><li>deploy the application to staging</li><li>validate the preview</li><li>merge the changes into the master branch</li><li>migrate the production database</li><li>make changes to the production Hasura instance with the Dashboard</li><li>deploy the application to production</li></ol><p>It's as good as it gets with a Serverfull solution. The main problem here is that Hasura is not build to support multiple branches. Additionally, the focus on Dashboard-driven-configuration makes it cumbersome to have multiple environments.</p><h2>How WunderGraph blends into your existing workflow</h2><p>Now let's compare this Workflow with WunderGraph, a truly Serverless solution, designed to support multiple branches and environments out of the box.</p><ol><li>scaffold a new project</li><li>make a few commits</li><li>push to a remote repository</li><li>hook up a CI/CD pipeline</li><li>deploy to production</li></ol><p>When you scaffold a new project, WunderGraph is already integrated into the workflow with our Starter Kits. There's no Dashboard, the configuration of both database and the API layer is done with code. This code is part of the repository, so it can be picked up by CI/CD pipelines automatically to deploy the frontend, migrate the database, e.g. with Prisma, and deploy the API layer.</p><p>You also don't have to integrate WunderGraph into your application. WunderGraph automatically generates a type-safe client to access your API, it's a single configuration parameter, and you're done with the integration. The generated client also handles the authentication flow and can be used to upload files. It's a production-grade end-to-end solution.</p><p>The best, fastest, and easiest to maintain code is the code we don't write. WunderGraph strives to remove as much code as possible from your application. This means you can deliver faster and you have less to maintain.</p><p>With Hasura, you've got to think about how you want to use your API. Do you lock it down? What client should you use? How do you add authentication?</p><p>Next, let's have a look at the workflow for continuous development:</p><ol><li>create a new branch</li><li>make a few commits</li><li>push to the remote repository</li><li>open a Pull request</li><li>preview gets deployed automatically</li><li>your colleagues can preview the changes</li><li>when you merge the Pull request, the preview gets deployed to production</li></ol><p>WunderGraph supports branches and environments out of the box. A different branch, a different environment, it's all just code. You don't have to manually configure anything with a dashboard, just change a few lines of code and git push.</p><p>As you can see, WunderGraph doesn't really change the workflow, whereas Hasura makes it a challenge at scale. Now, let's look at security.</p><h2>A different perspective on security</h2><p>In terms of security, both WunderGraph and Hasura follow a different paradigm.</p><p>Hasura exposes a GraphQL API and allows you to manually lock it down. By locking it down, they mean that you can create allow-lists of GraphQL Operations for production, but client and server still communicate using GraphQL over HTTP POST.</p><p>At WunderGraph, we've made an important observation of how developers use GraphQL APIs. When in production, almost no one changes their GraphQL Operations, they are static. So, if you're not changing your GraphQL Operations in production, why do you even expose GraphQL at all? Why not use GraphQL during development and replace static GraphQL Operations with JSON-RPC?</p><p>That's exactly what we're doing. Each GraphQL Operation is automatically compiled into a JSON-RPC call, while were also generating a type-safe client to access this RPC Endpoint.</p><p>So, WunderGraph looks like GraphQL, feels like GraphQL, but uses JSON-RPC over HTTP at runtime. This means it's more efficient, we're sending fewer data, and it's much more secure because the GraphQL API is not exposed to the public.</p><p>Why do we have to lock down a vulnerable API that shouldn't have been exposed in the first place?</p><h2>Hasura breaks with the Idea APIs in general</h2><p>Another aspect I'd like to discuss is that Hasura is breaking with the idea of APIs. Here's a quote from the API Mandate from Jeff Bezos from 2002:</p><blockquote><ol><li>All teams will henceforth expose their data and functionality through service interfaces.</li><li>Teams must communicate with each other through these interfaces.</li><li>There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.</li></ol></blockquote><p>Hasura automatically introspects your database, generates a GraphQL API from the tables, and exposes it to the public. You're not directly sharing the database, but your API actually leaks the implementation. So, while you're using GraphQL, you actually are exposing your database, even if the interface is different. This, by my definition, doesn't live up to the idea of APIs. APIs should hide the implementation, and expose a public interface. When you change a database table, your Hasura API will change as well.</p><p>This is a feature in the first week of your project, but it becomes a burden over time. If other teams and companies depend on your interface, but your interface actually represents your database, you're stuck in that you're not able to make breaking changes to the database schema.</p><p>Additionally, a GraphQL API, generated from the database, is not really an API that you could share with anybody. APIs need to be designed around specific use cases, activities, and interactions. If the tables in your database dictate the shape of the API, it's very unlikely that the result of the API will be useful to anyone who doesn't fully understand the data model of your database.</p><p>With WunderGraph, you can generate a GraphQL API from your database as well, but we're not exposing it. We expose a JSON-RPC API, with an OpenAPI Specification and generated clients. You can use the database generated API internally, but the public API will be defined by yourself.</p><p>Your users will get a Postman Collection, or a generated client/SDK, which really represents the possible use cases of you API, not just tables.</p><h2>Remote Schemas and API Composition / Federation</h2><p>Speaking of tables, your company is probably not built on top of a single database. You might have multiple databases as well as numerous internal and external APIs, REST, GraphQL, Apollo Federation, and so on...</p><p>To solve this problem, Hasura added a feature called &quot;Remote Schemas&quot;. Remote Schemas allow you to attach other APIs to the initial database-generated API. You attach a Remote Schema by configuration in the Dashboard.</p><p>There are two problems with this approach. First, Hasura requires you to have a database in the first place. But, what if I work in an environment where I don't want to have a database but simply want to use APIs?</p><p>Second, and that's probably the biggest problem here, the Remote Schema configuration is static, when it needs to be dynamic. Let me explain this in a bit more detail.</p><p>When you combine two APIs, you have to configure certain rules to make sure that the two APIs are compatible. For example, you have to make sure that there are no naming collisions. You might also want to set up links between the two APIs, e.g. to be able to join data across them.</p><p>The way you configure this in Hasura is by defining this in the Dashboard, for the current state, and that's the problem. APIs change all the time, so the Remote Schema configuration shouldn't be static. Instead, it should be defined like an arrow function. So, with the Dashboard approach, you can only configure the Remote Schema once. Whenever any of the APIs change, you have to reconfigure the whole thing. If you add links to fields, you have to link them again after re-adding the Remote Schema.</p><p>With the WunderGraph approach, adding a Remote Schema means that you're writing some code. Adding a link to a field also works by writing some code. This code can run over and over again, using continuous integration. So, the changes you've configured will always be applied automatically. You don't have to re-configure it over and over again.</p><p>In a world of constantly changing APIs, I don't believe in a tool that's not designed for this common use case. I think, Hasura has come a long way, but it's really visible that it was designed to expose your database, and not to compose and integrate APIs.</p><h2>Pricing.. The elephant in the room</h2><p><a href="https://www.reddit.com/r/Hasura/comments/10t26zj/hasura_went_full_bananas_with_new_pricing_model/">Hasura went full bananas with new pricing model</a></p><p>Hasura Cloud Pro recently underwent a pricing change... and the community was a bit shocked by this sudden change.</p><blockquote><p>Hasura updated their pricing model monthly $100 to $1.5 hourly (more than $1000) and limiting this with 120 requests per minute.</p></blockquote><p>With this in mind, it's time to address the elephant in the room. Price.</p><p>WunderGraph starts at just $25 per month, providing you with unlimited access for your entire team and multiple projects. You get 1 million API requests per month, and for every additional 1 million requests, it's just $10. Our pricing is remarkably affordable for devs and small teams looking to build quicky.</p><h2>Summary</h2><p>Some developers might like the Dashboard approach more, and I respect that..</p><p>But for those, who want to scale their architecture, automate as much as possible, and abstract away mundane repetitive tasks, I can definitely recommend WunderGraph as a viable alternative.</p></article>

wunderGraph-is-the-best-alternative-to-hasura

WunderGraph: A better alternative to Hasura Cloud

Looking for a better alternative to Hasura Cloud? In this blog post, let's highlight the key differences and similarities between WunderGraph and Hasura Cloud.

Making the right choice: WunderGraph or Hasura for your API architecture

<article><p>Are you looking for an open source alternative to Apollo GraphOS / Federation? Cosmo is a drop-in replacement. You can 100% self-host Cosmo, e.g. for compliance reasons, or use our managed Cloud.</p><p>My name is Jens, and I'm the Founder &amp; 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.</p><p>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.</p><h2>Apollo, successor to Meteor, the &quot;best way&quot; to build with GraphQL</h2><p>Geoff Schmidt, the CEO of Apollo describes Apollo as the successor to Meteor.</p><blockquote><p>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</p></blockquote><p>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.</p><p>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:</p><blockquote><p>The GraphQL developer platform.</p></blockquote><p>It's all about helping companies to build GraphQL APIs.</p><h2>Should you use Apollo for GraphQL? Or is there another way?</h2><p>WunderGraph, is a new way to think about APIs, leveraging GraphQL</p><p>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 &amp; development. We spent so much time composing APIs of different protocols, transports, and so on.</p><p>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.</p><p>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.</p><p>While using GraphQL as the language for API composition is promising, it's important to shift away from a &quot;server-full&quot; mindset. This shift can help us create more flexible and scalable solutions that meet the needs of modern development.</p><h2>Treating APIs as dependencies can transform your development process</h2><p>Let's try and understand this. What if we treated APIs as depedencies? Let me explain this a bit more in depth.</p><p>The traditional, Apollo-way of adding another internal or external API or database to a system is to extend &quot;THE Graph&quot;. 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.</p><p>We can borrow the solution from existing programming paradigms, it's called &quot;dependency management&quot; or, more well known, &quot;package management&quot;. If you need another &quot;package&quot;, you can npm install or go get it. The package manager manages the dependencies of you project and helps you to update them.</p><p>Now, APIs are not code. You can't just &quot;add an API&quot; to your application. It's a lot more complicated than that... or is it?</p><h2>GraphQL as the language for API composition</h2><p>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 &quot;API-full&quot;.</p><p>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...</p><p>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 &quot;package management&quot;.</p><p>In an exponentially growing system of APIs, you will eventually run out of resources to connect to &quot;gigantic&quot; 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.</p><p>In more technical terms, WunderGraph allows you to compose multiple API dependencies into a single unified Graph with just a few lines of code.</p><pre data-language="typescript">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],
});
</pre><p>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 &quot;executes&quot; your API composition.</p><h2>Should you expose GraphQL APIs?</h2><p>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.</p><p>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.</p><p>WunderGraph does out of the box:</p><ul><li>Input Validation using JSON-Schema</li><li>Injection Prevention / Process Validation (at compile time)</li><li>Query Limiting (Depth), Query Cost Analysis (at compile time)</li><li>Server-side batching and caching</li><li>Timeouts -Access Control protection with RBAC and ABAC</li><li>mitigates batching attacks</li><li>prevents introspection attacks</li></ul><p>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?</p><p>Interestingly, in the beginning, Geoff was hesitant to allow clients to send arbitrary queries to the server.</p><blockquote><p>Similarly, and also to accommodate larger and more complex apps, we would move UI component data dependency specification from the backend (a DDP &quot;publication&quot;) 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</p></blockquote><p>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.</p><p>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 <a href="https://docs.wundergraph.com/docs/guides/expose-a-graphql-api-from-wundergraph#the-solution-exposing-your-graph-ql-from-wunder-graph">GraphQL API</a>, even though we still reccommend against it!</p><h2>Comparing the WunderGraph Developer Workflow with ApolloOS</h2><p>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.</p><p>Let's break down the WunderGraph flow:</p><ul><li>Add API dependencies to your project</li><li>Define GraphQL Operations</li><li>WunderGraph generates a JSON-RPC API and a type-safe client</li><li>Deploy Serverless API Gateway alongside your frontend</li></ul><p>Now let's compare this flow with Apollo:</p><ul><li>Wrap all &quot;API dependencies&quot; in Subgraph</li><li>Compose the Subgraphs</li><li>Deploy the Supergraph</li><li>Add Apollo client to your Frontend</li><li>Define GraphQL Operations</li><li>Lock down the API, add authentication, authorization, caching, and so on via additional extensions</li></ul><p>The development workflow is quite similar, but the WunderGraph Architecture comes with batteries included.</p><h2>Open Source GraphQL Solutions</h2><p>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.</p><p>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, <a href="https://github.com/wundergraph/federation-benchmarks">as our benchmarks show.</a></p><p>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 <a href="https://www.elastic.co/licensing/elastic-license">Elastic 2.0 license</a>, while WunderGraph is licensed under the Apache 2.0 license. The <a href="https://github.com/wundergraph/graphql-go-tools">GraphQL Engine of WunderGraph</a>is licensed under the MIT license.</p><p>This means, no other company is allowed to use Apollo's implementation to provide a hosted GraphQL Gateway, while this is possible with WunderGraph.</p><p>In fact, the WunderGraph Federation implementation is a separate package (<a href="https://github.com/wundergraph/graphql-go-tools">graphql-go-tools</a>) 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.</p><h2>The elephant in the room: Pricing</h2><p>Given the recent changes in pricing from Apollo, I think it's important to highlight the key differences.</p><p>Although WunderGraph is open source, we do offer a cloud solution that includes free and paid tiers.</p><p>Both WunderGraph Cloud and Apollo have a generious free tier, but there are two major differences between them.</p><ol><li><p><strong>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.</strong></p></li><li><p><strong>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.</strong></p></li></ol><h3>Paid cloud plans</h3><p>With ApolloOS pricing starts at $500 per month, while with WunderGraph Cloud your pricing is $25 per month.</p><h3>Enterprise plans</h3><p>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.</p><p>Per Apollo's <a href="https://www.apollographql.com/docs/graphos/routing/self-hosted/">Documentation</a>:</p><blockquote><p>Self-hosted supergraphs are an enterprise-only feature for organizations with advanced performance or compliance requirements.</p></blockquote><p>Per WunderGraphs <a href="https://docs.wundergraph.com/docs/self-hosted">Documentation</a>:</p><blockquote><p>WunderGraph is fully open source and can be hosted with your favourite cloud provider</p></blockquote><h2>Summary</h2><p>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 &quot;Serverless&quot; API Gateways? Should we adopt &quot;THE GRAPH&quot; for all our APIs, or use GraphQL as a &quot;meta-API&quot; 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?</p><p>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.</p><p>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 &quot;API dependencies&quot;. GitHub and Open Source brought together developers to build and collaborate on common solutions, allowing for re-usability and composition.</p><p>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.</p><p>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.</p></article>

wundergraph-a-better-alternative-to-apollo-graphos

WunderGraph: A better alternative to Apollo GraphOS

Looking for a better alternative to Apollo GraphOS? In this blog post, let's highlight the key differences and similarities between WunderGraph and Apollo GraphOS.

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

<article><p>Are you looking for an open source alternative to Apollo GraphOS / Federation? Cosmo is a drop-in replacement. You can 100% self-host Cosmo, e.g. for compliance reasons, or use our managed Cloud.</p><p>Apollo just released their newest version of the Apollo Federation Gateway (v2), so I was curious how it performs against v1 and the WunderGraph implementation.</p><p>Both Apollo Gateway v1 and v2 are implemented using NodeJS, the WunderGraph Gateway is written in Go.</p><p><s>So far, WunderGraph is the only Federation implementation aside from Apollo.</s> It was brought to my attention that there's also mercurius-js that implements the Federation specification. It's built on top of Fastify (NodeJS). Thanks to <a href="https://twitter.com/matteocollina">@matteocollina</a> for pointing out! If you know any other implementation, please let me know!</p><h2>TLDR</h2><p>WunderGraph achieves up to 271x (132x) more requests per second vs. Apollo Gateway v1 (v2), 99th percentile latency is 292x (54x) lower. Apollo Gateway v2 achieves 2x more rps than v1, 99th percentile latency is 5.6x slower than v1. While Apollo Gateway v1 had problems with timeout errors, v2 solved this problem.</p><h2>Apollo Federation with Subscriptions</h2><p>In contrast to Apollo Gateway, WunderGraph supports Subscriptions. This is possible because Go has green threads (goroutines) which enable services to scale easily across all cores of a computer. Each Subscription can run in its own goroutine, which only takes up a few kilobytes of memory in stack size, so scaling this solution is quite efficient.</p><p>That said, getting the architecture right for federated subscriptions is a complex problem. Most if not all GraphQL server implementations &quot;interpret&quot; GraphQL Operations at runtime. This means, they parse the Operation into an AST at runtime and work through this AST to resolve the Operations.</p><p>WunderGraph takes a different approach. We've built a <a href="/overview/query-compiler">Query Compiler</a> that divides resolving a GraphQL Operation into multiple stages. On a high level, we differentiate between the planning, and the execution phase. During planning, we evaluate the AST and build an optimized execution Plan, hence the &quot;Query Compiler&quot;. This execution Plan can be cached, which makes this approach very efficient. But efficinecy is not everything. More importantly, this approach allows us to solve complex problems like resolving federated GraphQL Operations with a multi step compiler, combined with an optimized execution engine.</p><p>Btw. this Query Compiler and Execution engine is <a href="https://github.com/jensneuse/graphql-go-tools">open source under a MIT license</a>. It's used by more and more companies in production. We're very proud that the developers of Khan Academy joined the ranks of maintainers recently.</p><p>One last word on open source, graphql-go-tools, the library we're building WunderGraph upon, has some amazing contributors. Amongst them is <a href="https://github.com/chedom">Vasyl Domanchuk</a> from the Ukraine, he contributed the <a href="https://github.com/jensneuse/graphql-go-tools/pull/267">DataLoader implementation</a> that plays an important role in making the engine so fast. This implementation solves the N+1 problem when resolving nested federated GraphQL Operations.</p><blockquote><p>Thank you Vasyl, your work is highly appreciated!</p></blockquote><h2>Benchmarking methodology</h2><p>I've setup the basic Federation demo, more info at the end of the post. For benchmarking, I've used the cli &quot;hey&quot; with a concurrency of 50 over 10 seconds.</p><h2>Results - Apollo Federation Gateway vs WunderGraph</h2><h3>Requests per second (small Query)</h3><table><thead><tr><th>Gateway</th><th>Rps</th></tr></thead><tbody><tr><td>Apollo Gateway v1</td><td>195</td></tr><tr><td>Apollo Gateway v2</td><td>400</td></tr><tr><td>WunderGraph</td><td>53000</td></tr><tr><td>Mercurius-js</td><td>1883</td></tr></tbody></table><h3>Requests per second (large Query)</h3><table><thead><tr><th>Gateway</th><th>Rps</th></tr></thead><tbody><tr><td>Apollo Gateway v1</td><td>186</td></tr><tr><td>Apollo Gateway v2</td><td>293</td></tr><tr><td>WunderGraph</td><td>43834</td></tr><tr><td>Mercurius-js</td><td>208</td></tr></tbody></table><h3>Latency (small Query)</h3><table><thead><tr><th>Gateway</th><th>Avg</th><th>99th percentile</th><th>95th percentile</th></tr></thead><tbody><tr><td>Apollo Gateway v1</td><td>81</td><td>108</td><td>97</td></tr><tr><td>Apollo Gateway v2</td><td>97.1</td><td>194</td><td>127</td></tr><tr><td>WunderGraph</td><td>0.9</td><td>4.4</td><td>1.9</td></tr><tr><td>Mercurius-js</td><td>26</td><td>40</td><td>34</td></tr></tbody></table><h3>Latency (large Query)</h3><table><thead><tr><th>Gateway</th><th>Avg</th><th>99th percentile</th><th>95th percentile</th></tr></thead><tbody><tr><td>Apollo Gateway v1</td><td>115</td><td>287</td><td>114</td></tr><tr><td>Apollo Gateway v2</td><td>170</td><td>1609</td><td>614</td></tr><tr><td>WunderGraph</td><td>0.9</td><td>4.2</td><td>2.1</td></tr><tr><td>Mercurius-js</td><td>238</td><td>344</td><td>269</td></tr></tbody></table><h2>Observations</h2><p>Apollo Gateway v1 always has timeout errors under high load. The newer version (v2) fixed this problem. However, v2 seems to be not yet mature as requests per second ranged from 10 to 400 in some test runs.</p><p>I've also found that Apollo now configures their gateway to use Apollo Studio by default. As an alternative, they provide you a code snipped to use curl. Additionally, there's a link to the docs to enable the Playground again, running on your local machine:</p><pre data-language="typescript">import { ApolloServer } from &quot;apollo-server&quot;;
import {
  ApolloServerPluginLandingPageGraphQLPlayground
} from &quot;apollo-server-core&quot;;

const server = new ApolloServer({
  typeDefs,
  resolvers,
  plugins: [
    ApolloServerPluginLandingPageGraphQLPlayground(),
  ],
});

</pre><p>mercurius-js is written in NodeJS, similarly to Apollos gateway. For the server, it's using the Fastify framework, which is visible from the results. On small payloads, it comes out on top of Apollo by almost 5x in terms of rps. It only seems that it struggles with the large Query. This could be either processing more data in general or due to the higher amount of network requests, the gateway has to make. Something must be going that here, which makes mercurius fall behind Apollo on the large Query.</p><h2>Conclusion</h2><p>NodeJS is still not comparable in terms of performance vs. Golang. While the new version of the Apollo Gateway doesn't throw timeout errors anymore, it's visible that it doesn't scale well when GraphQL Operations become deeply nested.</p><p>Comparing the latencies of Apollo v2 for the small and large payload, it's observable that the numbers skyrocket when Operations become more nested.</p><p>WunderGraph on the other hand is not yet saturated with the workload. we could probably increase the nesting further until it has to give up.</p><p>If you want a fast Federation compatible Gateway solution, WunderGraph can save you a lot of money for hosting while <a href="/overview/api-security">increasing the security of your API</a>.</p><h2>What makes the difference?</h2><p>It's mainly two things. For one, WunderGraph is written in Go, a language that is much more capable when it comes to concurrent workloads like implementing an HTTP server. The second aspect is the architecture of WunderGraph. Instead of &quot;interpreting&quot; Operations, WunderGraph works with a <a href="/overview/query-compiler">Query Compiler</a> that prepares the execution of an Operation at deployment time, removing all the complexity of working with the GraphQL AST at runtime.</p><p>If you want to learn more on this topic, have a look at the overview on the <a href="/overview/query-compiler">Query Compiler</a>.</p><h2>Demo Setup</h2><p>WunderGraph: https://github.com/wundergraph/wundergraph-demo</p><p>Apollo: https://github.com/StevenACoffman/federation-demo</p><p>In both cases, I was using the upstreams implemented using gqlgen to eliminate perfomance issues on the upstreams.</p><p>If you want to reproduce the results, just clone the repos and use hey or similar tools to benchmark yourself.</p><h2>Test Query Small</h2><pre data-language="graphql">query {
    topProducts {
        upc
        name
        price
        reviews {
            id
            body
            author {
                id
                name
                username
            }
        }
    }
}
</pre><h2>Test Query Large</h2><pre data-language="graphql">query {
    topProducts {
        upc
        name
        price
        reviews {
            id
            body
            author {
                id
                name
                username
                reviews {
                    id
                    body
                    author {
                        id
                        name
                        username
                        reviews {
                            id
                            body
                            product {
                                inStock
                                name
                                price
                                shippingEstimate
                                upc
                                weight
                                reviews {
                                    body
                                    id
                                    author {
                                        id
                                        name
                                        reviews {
                                            body
                                            author {
                                                id
                                                name
                                                username
                                            }
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}
</pre></article>

Benchmarks of the Apollo Federation Gateway v1 and v2 vs. WunderGraph show that WunderGraph is up to 271 times faster than Apollo.

WunderGraph Cosmo

WunderGraph Cloud

WunderGraph Gateway

Use cases

Alternatives

Documentation

Examples

GitHub

Community

Changelog

Roadmap

Latest from the blog

OSS Analytics, Monitoring, and Tracing for Federated GraphQL APIs

Cosmo Router: High Performance Federation v1 & v2 Router / Gateway

Pricing

Blog