Hasura vs WunderGraph comparison: What are the differences?

From a high level perspective, both Hasura and WunderGraph give you "Instant GraphQL on all your data", as Hasura puts it. In this article, we'll break down the two solutions and compare them feature by feature. While we're probably biased, we try to actually look at the pros and cons of each solution and keep is as objective as possible.

We respect Hasura as a Company, they've done a lot for the GraphQL Community. From a product perspective, we believe that there's overlap in some areas while both solutions follow different philosophies. This post will discover both the similarities and differences and wants to give you guidance on when to use which solution.

Feature Comparison#

Instant GraphQL on all your Data#

The primary focus of Hasura is to generate a GraphQL API on top of a database. They support PostgreSQL, MS SQL Server, Amazon Aurora and Google BigQuery. However, looking at the docs, they focus mainly on PostgreSQL.

In terms of APIs, it's also possible to use REST, GraphQL and OData. Recently, Hasura added support to transform the generated GraphQL API into REST Endpoints.

WunderGraph supports PostgreSQL, MySQL, AWS RDS, AWS Aurora, AWS Aurora Serverless, MariaDB, SQLite, Microsoft SQL Server, Azure SQL, MongoDB and Planetscale, with CockroachDB coming soon. Under the hood, WunderGraph uses Prisma to interact with the database. This means, whenever a datasource becomes available on Prisma, we can add it in WunderGraph.

In terms of APIs, WunderGraph supports REST APIs and GraphQL, including Apollo Federation with Subscriptions. This means, WunderGraph does not just support GraphQL upstreams but can also act as an Apollo Federation Gateway, federating multiple SubGraphs with other services.

As far as we know, Hasura's remote Schema functionality doesn't support Subscriptions. With WunderGraph, GraphQL Subscriptions are supported, even with multiple GraphQL Upstreams and Apollo Federation.

So far, we see there are a few differences between the two, but both tools offer more or less the same features.

However, there's one big differentiator already. Hasura is built around the idea of having a database. Without a database, you're not able to create a Hasura API.

WunderGraph on the other hand does not rely on a database at all. You're free to compose your schema solely from REST and GraphQL APIs. That's because our philosophy is slightly different.

Hasura puts the database at the center of everything. You start with a central database schema and can extend it by using APIs.

WunderGraph puts the API at the center. An API could be anything, a REST API, a GraphQL API, one or more federated SubGraphs or a database. In that sense, a database is just another API.

Remote Schemas#

Hasura has the concept of Remote Schemas. If something can be remote, it means that there's also a non-remote Schema, the schema of the central database. Additionally, there is a way of building relationships between remote schema fields and the central database.

WunderGraph doesn't distinguish between remote or non-remote schemas. Instead, everything is a remote schema. This also means, you can build relationships between any API. You can combine a GraphQL API with a REST API and build relationships between the two.

As mentioned earlier, Hasura Remote Schemas have some limitations, e.g. lack of support for Subscriptions.

Setup and Configuration#

In terms of configuration, both tools follow a completely different paradigm.

Although Hasura can be configured through a REST API, the primary method of configuration is their User Interface. From adding a Database to configuring remote schemas and relationships, all configurations can and should be done using the user interface. This pattern gives a nice onboarding experience as it's easy to learn.

WunderGraph doesn't come with a user interface for configurations. That's because we don't believe that infrastructure, like APIs, should be configured using a UI. APIs are an evolving system, they are always changing and moving forward. We believe that it's important to keep track of all the changes that are being made. We believe that you want to and operate APIs in different environments, e.g. dev, staging and production. We also believe that forms and buttons are too limited to configure complex API environments.

That's why we decided against configuration through user interfaces. Instead, WunderGraph comes with a powerful TypeScript SDK. This SDK allows you to configure your environments very easily and store all your configurations in git. You get out of the box versioning of your configuration, you can easily review and roll back, and it's possible to use branches for different environments. Once a change is tested in staging, it can be merged into production. WunderGraph is designed from the ground up to support these flows.

So, if you're someone who wants to configure their APIs using a user interface, you might lean towards Hasura. If you're into "infrastructure as code", WunderGraph suits you better.

Authentication#

Hasura doesn't handle Authentication for you so you have to integrate another service or build a solution on your own.

With WunderGraph, we've gone the extra mile to build an amazing Authentication Developer Experience. We don't just support OpenID Connect for authentication, we also generate a fully type-safe client that knows how to authenticate with your configured auth providers. In a nutshell, you configure an authentication provider, like Keycloak, Auth0, Okta, etc... This generates the backend functionality to handle the authentication flow as well as a client to handle the client-side part. All you have to do is connect a login() function to the user interface and your login is done. You can read more about this feature in the docs.

Authorization#

Hasura implemented authorization via a role based access model. Additionally, it's possible to use row level security, which makes sense for a tool that's so close to the database. Permissions can be configured using the Hasura Dashboard. With remote schemas, things get a bit more tricky. You can define a specific schema using SDL for each role to limit access. As an alternative, it's possible to forward headers to a remote schema.

From my point of view, Role based access seems to be a very solid solution, especially when used with a database like PostgreSQL that supports row level security. That said, it seems like authorization for remote schemas is an edge case, which the system is not optimized for.

WunderGraph has a different opinion on Authorization. We have an OpenID Connect integration for authentication, meaning that the user has an identity out of the box. This identity is not driven by WunderGraph itself. The source of truth is the identity provider. This means, you can configure and manage your users from within your identity provider. Depending on the roles and permissions you grant to your users, they will have different "claims", which can be used when interacting with WunderGraph APIs.

Using our claims injection feature, you're able to use claims from the identity provider and inject them directly into the GraphQL Operations. You can read more on the topic of claims injection here. Let me give you a short example of the power of this feature.

mutation (
    $name: String! @fromClaim(name: NAME)
    $email: String! @fromClaim(name: EMAIL)
    $message: String! @jsonSchema(
        pattern: "^[a-zA-Z 0-9]+$"
    )
){
    createOnepost(data: {message: $message user: {connectOrCreate: {where: {email: $email} create: {email: $email name: $name}}}}){
        id
        message
        user {
            id
            name
        }
    }
}

This operation, when executed, creates a post on behalf of the user. The variables NAME and EMAIL are automatically injected into the operation.

This means, if your database supports row level security (rls), e.g. PostgreSQL, you can inject the email of the user and let to its thing.

Additionally, we have hooks that allow you to validate the claims of a user before executing an operation by writing a TypeScript function. This means, you can limit access to any API, file uploads, mutations, etc. by evaluating the roles and permissions of a user, defined by the identity provider. This gives you full flexibility while keeping the configuration easy to maintain.

On top of that, WunderGraph comes with a Role Based Access Control implementation. When the user authenticates the first time, you're able to assign roles to them using a TypeScript function. You could for example give them different roles based on their email address. As the TypeScript hooks are just NodeJS, you're also able to fetch data from an external system or even a database to assign roles to a user. Once the roles are assigned, you're able to protect your Operations using the @rbac directive.

This example shows that only users with the role superadmin are allowed to delete messages by user email.

mutation ($email: String!)
    @rbac(requireMatchAll: [superadmin])
{
    deleteManymessages(where: {users: {is: {email: {equals: $email}}}}){
        count
    }
}

To sum up this section, both Hasura and WunderGraph offer many ways of implementing authorization for your APIs. The only distinction I'd make is that WunderGraphs authorization system is designed to work well with many "remote schemas", Hasura on the other hand works great when you want to use PostgreSQL native features.

API Security#

Opening up a GraphQL API to the public means, you have to carefully think about security. I've written extensively about the topic in a blog post if you want to get more insights into the complexity of securing a GraphQL API.

Hasura offers many features to combat this issue. Amongst them is depth limiting, node limiting, rate limiting, disabling introspection in production, allow lists.

One thing they seem to misunderstand is the use of CORS. CORS is not protecting the server, it's protecting the user. If a user is authenticated and visiting a different domain, CORS allows you to control if you accept the authentication information from the user, even if they are on a different domain. However, as Hasura is using JWT for authentication, this scenario is very unlikely as an attacker would only have to steal the JWT token. CORS makes sense when using cookie-based authentication.

WunderGraph thinks differently about API security. Our opinion is that exposing a GraphQL API is a rabbit hole you don't want to get yourself into. It's a cat and mouse game. It's almost impossible to prove that your whole Schema is secure. Even if you believe that you've done everything you could, a hacker might still find an opportunity to exploit your system.

Instead of exposing a GraphQL API and trying to secure it, we simply only expose a JSON-RPC API. During development, you define all the Operations you need. These are then immediately turned into a JSON-RPC API. This JSON-RPC API only accepts variables, is protected by an authentication- as well as a JSON-Schema validation middleware.

As a JSON-RPC would be somewhat hard to use, we've also created a code-generator to generate a 100% type safe client based on the JSON-RPC API. We'll come back to this client later.

Input Validation#

As described in the last chapter, WunderGraph creates a dedicated endpoint for each GraphQL Operation you define, but that's not all. Both the inputs and the response of an Operation can be expressed as a JSON Object. WunderGraph parses the GraphQL AST of each Operation and generates a JSON Schema for it. This way, we can easily validate the inputs of an Operation.

Thanks to the custom @jsonSchema directive, it's possible to extend the JSON-Schema validation directly from within the Operation Definition. Here's an example adding a title, description and a Regex pattern to extend the JSON Schema.

mutation (
    $message: String! @jsonSchema(
        title: "Message"
        description: "Write something meaningful"
        pattern: "^[a-zA-Z 0-9]+$"
    )
){
    createPost(message: $message){
        id
        message
    }
}

What's beautiful about this approach is that you're able to re-use the generates JSON-Schema in other parts of your application, for example the frontend. One great use of this is our integration with react-jsonschema-form. It allows you to generate complete React Forms, just by writing a GraphQL Operation, as the library can pick up the JSON-Schema as well.

Hasura suggests to use Postgres check constraints or triggers for input validation. Another Option is to use custom Hasura Actions which we will describe in the next chapter.

I personally don't think input validation should rely on the database. Not all database management systems offer the same functionality. Also, I want to be able to stop the operation as early as possible if the input is invalid. Finally, I don't want to depend on a specific database when building my application. In my opinion, JSON-Schema validation at the API gateway level is the clean approach to the problem of input validation.

Customization of the API#

When generating an API, customization is always an important aspect. Both WunderGraph and Hasura offer different ways for extensibility, let's break them down.

First, Hasura has what they call "Actions". Actions are custom additions to the schema, backed by a REST API. So, you can define a custom extension using GraphQL SDL and then configure a REST API webhook to implement it. The REST API needs to be deployed by the user itself, adding some complexity to the deployment and operations. The Dashboard also offers a code-generator to simplify building actions.

Aside from Actions, Hasura also has Event- and Scheduled Triggers. These can be invoked on specific events, e.g. when a row is inserted into the database, or based on a cron definition.

Finally, as we've discussed earlier, Hasura allows you to add Remote Schemas.

Moving onto the WunderGraph solution. First, as we've outlined at the beginning, there's no concept of a Remote Schema in WunderGraph. Every Schema is remote. WunderGraph also supports REST APIs by introspecting the OpenAPI Specification (OAS). So, instead of extending the Schema with the SDL and then implementing the change with a WebHook, you can go the other way around. Define a REST API or GraphQL API using OAS or GraphQL and simply merge it to your graph. That's a lot more convenient and makes it easy to add existing REST APIs to your unified graph.

Second, WunderGraph has a similar concept to Actions, Hooks! As all Operations are defined by a JSON-Schema, we're able to re-use this Schema to scaffold the structure of the hooks. So, whenever you define a new Operation or modify an existing one, we re-generate the code to define the Hooks. Currently, we allow you to write Hooks using TypeScript, but we could generate them in any language if required. As the type definitions for the hooks are automatically generated, all you have to do is implement the desired hooks, e.g. pre mutation, post query, synchronous or asynchronous, depending on if you want to modify the inputs or response or not.

You also don't have to deploy the hooks. WunderGraph automatically takes care of bundling the TypeScript code as well as running it alongside the gateway. Hooks use plain NodeJS, so you can use any npm package you want. All this makes Hooks very powerful, frictionless and easy to use.

Mocking#

One important aspect of the lifecycle of APIs is mocking. Sometimes, you don't want to test against a real system or, during development, the system might simply not be available.

For that reason, we've embedded first class support for Mocking directly into WunderGraph. As each Operation has clear inputs and outputs, defined by a JSON-Schema, it's easy for us to generate a TypeScript skeleton which the user can use to mock the response of an Operation.

All you have to do is implement one or more of the functions and your mock is ready. The skeleton is generated using TypeScript, so you can rely on type safety when writing the mocks. Additionally, as it's just using NodeJS behind the scenes, you can use any npm package you want to implement your mocks, e.g. faker js. You also don't have to take care of the deployment, it's all managed by the framework for you.

Looking at the docs of Hasura, I didn't find any info on mocking. As their primary use case is to sit in front of a PostgreSQL database, it's probably very rarely the case that this database is not present, so mocking is not that important in this use case.

I believe, especially in scenarios where you integrate with many APIs, mocking is essential to the development process as you're not always able to use all "real" APIs during development, e.g. when building the user interface to transfer money.

Local Development#

We've carefully designed WunderGraph from the ground up to best support local development and create a great onboarding experience. Our binaries are compiled for every major platform, including MacOS arm64 and Windows.

Getting started with a new WunderGraph project from scratch is as simple as:

yarn global add @wundergraph/wunderctl
wunderctl init --template nextjs-starter

This creates a complete WunderGraph enabled NextJS application with lots of examples to start with.

With Hasura, you have to follow a multi step process to get up and running on your local environment. Both services offer essentially the same outcome, it's just that we at WunderGraph automated the whole onboarding process to make it as fluent as possible.

Monitoring & Observability#

Hasura offers a boatload of information, when it comes to observability. Time of query, execution time, IP address of the client, identifying slow Queries, error tracking, distributed tracing, monitoring of WebSocket connections.

Our plan at WunderGraph to tackle Observability is twofold. For one, we want to build integrations for popular analytics and observability solutions, like Datadog, Splunk, OpenTracing and OpenTelemetry. On the other hand, we want to offer a managed solution in the future to give you a great analytics solution out of the box. Please contact us if you're interested in such a solution!

Caching#

Caching is an important aspect of every application. Every layer of an application should use caching if it can help make the application more resilient and can contribute to the performance.

Hasura allows caching of GraphQL Operations using a LRU cache. They've created a custom directive to allow the user to cache individual Operations with a specified time to live. Keep in mind that this layer of caching applies to the GraphQL execution.

Hasura also uses PostgreSQL prepared statements to improve performance. This way, SQL query plans can be cached so that they can be re-used. Additionally, it's possible to cache remote GraphQL APIs.

Finally, Hasura suggests generating REST APIs to enable "traditional" caching. I personally wouldn't call it traditional. If you look at the different layers of the web, you realize that Browsers, Proxies, CDNs

Realtime Subscriptions#

One of the core capabilities of Hasura is to offer GraphQL Subscriptions on top of PostgreSQL using polling. It's a simple solution that scales very well, thanks to the smart engineers at Hasura. They accomplished to optimize the SQL AST so that they can do the "polling" for multiple Subscriptions using the same SQL Query.

WunderGraph does a similar approach. We're also using polling to implement "streaming updates". You're able to configure the polling interval on a per-Operation level, meaning that you can adjust the "liveness" for each of your operations. Additionally, polling doesn't just work for databases but for every DataSource, including GraphQL and REST.

Another difference is the transport. Hasura relies on WebSockets, an unmaintained HTTP 1.1 specification. WebSockets offer a very poor API in the web. E.g. it's not possible to send Headers with the Upgrade request. For that reason, you have to find custom solutions to implement authentication via WebSockets. These solutions usually expose API tokens to the browser, which is generally insecure.

WunderGraph on the other hand exposes Subscriptions as an HTTP/2 stream, with a fallback to chunked encoding, if HTTP/2 is not available. This way, we're able to use secure HTTP only cookies with strong encryption to keep API tokens out of the browser.

Both Hasura and WunderGraph offer a solution for realtime Subscriptions, with WunderGraph focussing a bit more on security.

File Uploads#

Building an application means you don't just deal with structured data but also files in the form of images, pdfs and more. We've realised that it creates a lot of overhead if file uploads would be managed using a different system. If that were the case, you'd have to implement authentication twice, adding complexity to the system.

Instead of putting this burden to our users, we've gone the extra mile and added native file management support to WunderGraph. You can plug in any S3 compatible file storage, allowing you to upload files to your on premises Minio, AWS S3 in the cloud or any other S3 API compatible storage provider. You can read more on the topic in the docs.

Hasura decided not to support unstructured data but focuses only on the GraphQL API. Sometimes it's a good decision to focus on one problem. With WunderGraph, we'd like to offer an end-to-end solution so that our users don't have to puzzle too many dependencies together.

Tight coupling between Client & Server#

One of my biggest criticisms of generated GraphQL APIs is that they introduce tight coupling between client and API implementation. If the API is generated from the database, a change to the database will automatically introduce a breaking change for the client. This works well if you're a single developer or small team, but doesn't scale across an organization with multiple teams. You absolutely want to be able to change the way you store data without breaking the API.

This problem is very present in Hasura. Change a table name or a field and your API consumers have to deal with a breaking change.

As you might have already learned, WunderGraph does not directly expose a GraphQL API. Instead, we're using the Operations to define JSON-RPC Endpoints. For each of the endpoints, we're able to generate a Postman Collection, as they behave like simple REST APIs with specific inputs and outputs.

An additional benefit of having this "intermediate" RPC API in front of the GraphQL Schema is that we're able to abstract away the implementation from the API contract with the client. Through analytics, we're able to tell exactly which clients use which "RPC Operations". This enables us to swap the complete implementation of the API, without breaking the RPC contracts. You can change the database or even replace it with a custom GraphQL API, just make sure to implement a middleware that implements the RPC contract for the existing clients, and you can make the change without breaking anything. We wrote extensively about this in our blog post on versionless APIs.

We believe that versionless APIs is the key to enable businesses to collaborate using APIs. API integrations across teams or even companies can only scale when the contracts between them are stable. Making APIs backwards compatible for a long time is the key to building these stable contracts.

Generated Clients#

WunderGraph is not just a solution to generate a backend, but also comes with a code generator to generate 100% type safe clients that work hand in hand with the API you create. Once you define your Operations, WunderGraph generates both, the API endpoints and the client. We currently support TypeScript and ReactJS as templates but you're able to extend this with your own custom templates, allowing you to generate code for any platform, language or framework.

Authentication-Aware Data Fetching#

Generating not just the backend but also the API client comes with a lot of additional benefits. One of them is authentication-aware data fetching.

At the time when the WunderGraph code-generator generated the client, it knows about all the Operations and if they require the user to be authenticated. The developer can change this with a configuration parameter.

This information makes it possible to generate the client in a way so that it's aware if authentication is required for an operation or not. If an Operation requires the user to be authenticated, the client will automatically "wait" until this requirement is met. Instead of trying out the operation, resulting in a 401 unauthorized, the client can immediately indicate that the prerequisites to make the request are not (yet) met. Additionally, once the user authenticates, the Query or Subscription can immediately fire off to load the data. The developer doesn't have to write additional logic to handle these states.

As Hasura doesn't generate clients, you have to implement this logic on your own.

CSRF Protection#

Another important aspect of APIs is security. What's important is that you make sure that your users are not tricked into a situation where they "mutate" state unintentionally. That is, you want to make sure that an API user only sends money when they intended to.

There are standardized methods of solving this problem, well known as CSRF protection. If the user is authenticated on your domain, CSRF protection makes sure that a request from another domain cannot easily do a mutation. CSRF protection is not trivial to implement and requires some knowledge about security.

As we're generating both the backend and the API client, we were able to embed CSRF protection into both of them. If you define a mutation using WunderGraph, the resulting API is automatically CSRF protected. You don't have to do anything!

Cross API Joins#

Both Hasura and WunderGraph support to join data across APIs. Hasura does the join at the Schema level, WunderGraph does the join at the Operation level.

Let's explore both solutions and compare them, starting with Hasura.

The way Hasura approaches cross API joins is by allowing the user to add a remote Schema to the existing Database-driven API. You're then able to configure which arguments (foreign keys) to use to join a field from the Database Schema and the remote Schema.

The result is a new Schema that combines both, the Database-driven Schema and the remote Schema. The API user will not notice that they're joining data from two different APIs as it's just a single GraphQL API.

The approach is called "Schema Stitching" and is widely used in the community.

At WunderGraph, we've looked at Schema Stitching for a while and decided that we don't want to make it the primary method of joining APIs. Schema Stitching as well as Apollo Federation are supported methods of joining APIs by WunderGraph, but we've also developed a new approach: Nested Query Type Joins. Let me explain.

Our goal at WunderGraph is to allow APIs to be small building blocks that can be combined with other APIs to solve a problem, like lego blocks.

We've done experiments with Schema Stitching and realized that it has some limitations that make it hard to scale. The more APIs you're trying to stitch, the more complexity you add. As the number of APIs you're joining grows, you run into more and more problems, like naming collisions. To solve these problems, you'd have to add custom stitching logic which becomes hard to maintain.

Our solution to the problem is two-fold. First, we use namespacing to avoid naming collisions. Second, we've implemented cross API Joins at the Operation level.

What does this mean? Let's look at an example:

query ($code: ID! $capital: String! @internal) {
    country: countries_country(code: $code){
        code
        name
        capital @export(as: "capital")
        weather: _join @transform(get: "weather_getCityByName.weather") {
            weather_getCityByName(name: $capital){
                weather {
                    summary {
                        title
                        description
                    }
                    temperature {
                        actual
                    }
                }
            }
        }
    }
}

This Operation fetches a country by code and joins the weather data from the weather API. We're using some special directives to make this work, but most importantly, it's a 100% valid GraphQL Operation. Existing tooling, like your IDE can validate the Operation, intellisense and code completion will work as expected.

This approach scales well, because you're able to add as many APIs to your virtual Graph as you want. Namespacing will keep each API separate, and you can easily add new APIs without having to change your existing code.

WunderHub - The Package Manager for APIs#

WunderGraph is not just an Open Source Framework to build secure Applications faster, it also comes with powerful tools to enable new levels of API collaboration.

Imagine you're working in a team and you want to easily share your APIs with your colleagues, the whole organization or even developers in other companies.

WunderHub gives you an easy way to share APIs and integrate them into your existing applications. It's tightly integrated into the WunderGraph ecosystem, allowing for a great collaboration experience.

We don't see APIs as isolated islands. APIs are the key to sharing functionality with other developers, encapsulated in small building blocks.

WunderHub allows you to easily share these building blocks, allowing others to build on top of them.

Technical Comparison#

Both WunderGraph and Hasura are built on top of high performance languages, with Hasura built using Haskell, and WunderGraph implemented using Golang.

Both languages are compiled and therefore very fast. They also both come with their own scheduler, meaning that asynchronous workloads can be multiplexed across many CPU threads, allowing both languages to scale well across multiple CPUs. Compared to e.g. NodeJS, they can easily max out a CPU.

On the TIOBE index, Golang ranks 18th @ 1.21%. Haskell ranks 40th @ 0.24%. It should be much easier to find Go developers than those familiar with Haskell. Golang is also used in a lot of large projects, like...

• kubernetes
• cockroachdb
• etcd
• Docker
• consul
• Terraform
• syncthing

Why is WunderGraph a great Hasura alternative?#

If all you want to do is expose a pure GraphQL API from a database, Hasura is a good choice.

However, if you already know that you will be exposing your API to web clients on the public internet, there's a lot more work to be done than just exposing the GraphQL API itself. You have to secure the API and build your own custom client on top of it that handles caching, authorization, authentication, secure data fetching, CSRF protection, file uploads and more.

With WunderGraph, you get an opinionated well maintained framework to solve all these problems for you. If you're solving all these problems on your own, think about who's going to maintain your custom solution, who will update the dependencies of your GraphQL client, and who makes sure your authentication implementation is actually secure?

All this work can be solved by the framework, which can be collectively maintained. Why use custom proprietary code that you have to maintain yourself, when it can be abstracted away into a framework? We offer many ways to customize the behaviour, but the very core should not be maintained by individuals.

Our goal is to standardize the way we integrate and consume APIs and make the solution available as an open source framework. This way, you can use best practices and proven patterns in almost all layers of your application without a custom implementation.

Get Started with WunderGraph#

Have a look at the docs or try out the Quickstart.

Are you still gathering information? Read more on all the features WunderGraph is offering. Learn more on API-Mesh and API Security as well as a section to explain WunderGraph to different personas.

If you're a developer, the easiest way to get started is to copy & paste this snipped into your terminal.

yarn global add @wundergraph/wunderctl@latest

mkdir wg-demo && cd wg-demo

wunderctl init --template nextjs-starter

yarn && yarn dev