Hasura vs Apollo: Comparing GraphQL Platforms

This post compares Hasura and Apollo GraphQL platforms, highlighting Hasura's fundamentally better approach to GraphQL. Hasura generates high-quality subgraphs from diverse data sources, providing a domain-first method for scalable and maintainable architectures, unlike Apollo's schema-first approach.

Essentially,

• Hasura can be used to generate high quality, composable subgraphs on any data source. The subgraph can be used in other federation tools to build a federated GraphQL API.
• Hasura can help you build a supergraph that is highly composable, backed by declarative AuthZ.

If you are already in your Apollo Federation journey, Hasura and Apollo Federation work well together. We have a newer post on how Hasura and Apollo works together in a GraphQL Federation scenario with accelerated subgraphs.

GraphQL has gained prominence for developing modern apps because of its flexible querying, efficient data fetching, strong typing and self-documentation.

Hasura is a popular choice for generating GraphQL APIs because it allows developers to instantly go from data source to API, bypassing a lot of the manual effort and time required to build GraphQL backends.

When talking to developers evaluating Hasura, we are often asked how Hasura compares with Apollo GraphQL, another popular tool in the GraphQL ecosystem. While the two technologies co-exist in the GraphQL space, the amount of code, time, effort, and skills it takes to go from data to production-grade GraphQL API is very different in Hasura and Apollo.

In this blog, we will share our (opinionated, but grounded) perspective on why Hasura is better than Apollo for building and running production GraphQL APIs at scale in most enterprise use cases.

Hasura is a data API automation platform that removes the tedious parts of building and operating production-ready APIs on data. With Hasura, developers don’t need to write GraphQL resolvers or boilerplate CRUD code or spend precious time adding access control, performance optimizations, or security limits into your API to get it operational.

Apollo is a GraphQL tooling company that provides a set of open-source and proprietary tools to enable developers to build apps with GraphQL. Apollo Server is the JavaScript implementation for writing a custom GraphQL server. Apollo Client is a front-end SDK to integrate GraphQL in client-side apps. Apollo GraphOS is the platform for building, managing, and scaling a supergraph (a federated graph composed of several subgraphs).

We will primarily compare Hasura vs Apollo Server for creating individual GraphQL services or endpoints. While we’ll touch on how Hasura compares with Apollo GraphOS for composing, managing, and evolving a federated graph, a more detailed comparison of the two technologies for GraphQL Federation use cases will be made in a follow-up blog.

Hasura’s main value over DIY GraphQL tools like Apollo is time to value. For the data sources it supports (see full list), Hasura eliminates or automates 50-80% effort that goes into building, securing, deploying, and scaling production APIs. By radically compressing the API development timelines, enterprises can shave off months/years of effort from their modernization projects with Hasura.

"If we had gone the traditional way this process would have taken us 2-4 years. With Hasura, we have been able to crunch it to just under a year. Achieving this timeframe in a highly regulated environment like healthcare is phenomenal.”                                                                                             Karthik Srinivasan, Solution Architect, Philips Healthcare

Time to API

Hasura auto-generates a full-featured and customizable GraphQL API endpoint from your database in minutes. With DIY GraphQL using Apollo, you need to write a lot of boilerplate code (resolvers, schema, etc.) to get a basic API running.

With Hasura, you can go from a new or existing data source to a fully featured API in minutes. Once connected to a database, Hasura automatically generates a GraphQL endpoint with all the core GraphQL operations like queries, mutations, and subscriptions based on the schemas of the connected data sources. This means you can start querying tables and views with filtering, sorting, pagination, joins, pattern search, and much more in a matter of minutes.

If you are using the Apollo Server, you would need to manually write the resolvers to generate the GraphQL APIs. It’s a lot of code and resources to create a boilerplate CRUD API.

In contrast, Hasura uses a JIT compiler approach to automatically compile GraphQL queries into a single SQL query to be executed on the database, completely bypassing the need for writing resolvers – a huge productivity boost.

And this is just to get a basic CRUD API. With DIY GraphQL, developers have to spend a lot of time adding security, performance, and scalability to get the API ready for production. Many tasks are also simplified in Hasura through built-in features highlighted in the following sections.

Performance

Hasura dynamically compiles your GraphQL query into a single database query that is highly optimized for the underlying datastore the data is being fetched from, giving you a fast API out of the box. With DIY GraphQL on Apollo, API performance needs to be manually tuned by the developer building the server and relies on knowledge of GraphQL and database performance best practices.

Hasura is a metadata engine that dynamically compiles a GraphQL query (of any depth) to a single database query in real-time. The compiled GraphQL queries are efficient and highly optimized for the underlying datastore and don't have the typical N+1 problem with GraphQL.

With DIY GraphQL approaches like Apollo, a developer needs to spend significant time tweaking their code to make it performant (for example, avoiding the N+1 problem). The problem can become more difficult when multiple teams/developers are collaborating on an API.

Hasura also avoids the cartesian product problem while fetching data from underlying systems by performing JSON aggregations in the upstream database itself. This is usually not the case with DIY GraphQL servers like Apollo since the SQL for JSON aggregations are not generated with ORMs.

You can further boost API performance with the native query response caching feature in Hasura that works automatically with an embedded Redis instance. (Read more about Hasura Caching). Apollo Server requires a manual setup of a cache backend like Redis.

Finally, Hasura uses predicate pushdown to embed authorization rules into the single query run on the databases. Not only is this better from a security perspective, it’s also more performant by avoiding multiple roundtrips to execute authorization logic coded in a separate layer. Embedding authorization rules into the SQL query of the resolver is a lot of work that would amount to building an engine like Hasura.

See our recent benchmark tests where Hasura was 3.6x faster than DIY GraphQL APIs on PostgreSQL. The performance difference was more prominent in complex queries where multiple levels of nesting to fetch related data are requested, in line with GraphQL fetch-what-data-you-want principles.

Bonus: Cost savings!

Most of Hasura’s performance advantages come from the compiler-based approach that allows Hasura to fetch the required data (and nothing else) from the underlying datastore in a single highly-optimized SQL query. This translates to cost savings by minimizing network hops and data egress, which can add up quickly for data-intensive applications.

"Hasura reduced our client data fetching time from 10 seconds to less than 1 second, which greatly improved the user experience." Read more about Cajoo’s case study.

Authorization, Security, and Governance

Hasura comes with a powerful authorization engine that allows you to define fine-grained access control policies in a simple, declarative manner.  With a DIY Apollo solution, you need to manually parse the context details of the request and write extra code logic to handle authorization.

Hasura comes with a powerful security and rule engine that handles schema, model, and field-level authorization. Hasura’s authorization engine helps model the following types of common authorization requirements:

• Role-based
• Attribute-based
• Rule-based
• Inheritance composition
• Row-level
• Field/column level

The declarative nature of Hasura authorization lets organizations easily enforce, review, and audit security rules, without talking to developers or dealing with code.

The authorization model on Apollo is based on forwarding the request “context” to the resolvers, where you have to manually parse the context details like the headers to create logic for authorization. For a complex permission system, this is challenging to replicate and maintain in your code base.

Moreover, Hasura’s authorization engine uses a predicate push-down model that is secure, and also more performant. Apollo does not do a predicate push-down. The database query generated through ORMs and other forms does not embed the user context to multiple depths of a query; and in cases where you want to, it is not trivial. And since this is code written manually to apply these rules, it is error-prone.

"By using Hasura, we cut the development time in half and built our product in 3 months. The built-in role-based authorization system made it easy to secure our data."
Read the Pulley's case study

For runtime security, Hasura supports setting API rate limits based on authorization attributes and user roles. It also provides advanced security for GraphQL subscriptions and WebSockets to prevent DoS attacks, malicious users, and badly configured clients. This is not possible with Apollo Server and usually requires integrating an external library or service and additional custom code.

Developer Experience

With GraphQL and Hasura, frontend developers are empowered to feel like full-stack developers since it gives them the power to quickly create, modify, and iterate on the API layer without getting blocked on other teams. This is made possible by a bunch of features that Hasura provides, but more importantly, it’s just a great developer experience, to begin with.

Hasura is declarative and metadata-driven. Apart from the custom logic code that is integrated with Hasura, everything else can be ported to different environments in a few clicks or commands. Hasura Console UI lets you create, manage and test GraphQL APIs and the data sources connected. Hasura CLI tool lets you manage metadata.

Apollo Studio is the UI element in the GraphOS stack. It helps you manage your GraphQL schema, analyze usage, and explore APIs. Apollo Studio lets you manage the subgraphs, org-level access control, and GraphQL schema via their Schema Registry interface.

Hasura Console, on the other hand, gives a powerful user experience for managing connected data sources via a database manager UI. Here you can create and manage schemas and tables and establish relationships between them. You can also configure the GraphQL Federation API by adding any external GraphQL API and setting up joins between them. Hasura’s Authorization system is declarative and easy to define, thanks to the Console experience.

Using the Hasura Console and CLI, you can automate the creation of database migrations that can be applied to different environments. Apollo’s GraphOS platform doesn’t deal with databases in its workflows.

With Apollo Server, you are also bound to write a custom GraphQL implementation with JavaScript. If you want to switch to a different language or framework, you need to go outside the Apollo stack and add them as a subgraph. GraphQL implementations are not known to be optimized for performance in all languages and frameworks. As the official GraphQL spec changes, everything gets ported to the native JS implementation and might take a while to reflect in other languages and frameworks, including Apollo. The experience is different as limitations differ in different implementations.

Real-time APIs and apps

GraphQL Subscriptions in Hasura are automatically generated, highly scalable, and provide usage analytics out of the box which is hard to replicate in a DIY setup.

Hasura offers real-time data synchronization out of the box. Hasura uses WebSocket connections to push data changes to clients in real time. This means that clients receive updates as soon as they are available, without needing to refresh the page or make additional requests.

Real-time APIs over WebSockets are quite stateful and expensive, making them incredibly difficult to deal with in production. WebSockets need another layer of web security implemented. Hasura’s authorization system ensures that it sends the correct events to the right consumers.

Apollo also offers real-time data synchronization, but it requires additional setup and configuration and developers have to write server code to handle WebSocket connections. A custom pub-sub implementation is required with Apollo. It becomes even harder when authorization is involved for a custom-written real-time API since this state needs to be managed somewhere and the results need to be filtered at the source layer, in real-time.

Hasura is also able to give insights into usage analytics for GraphQL over WebSockets and GraphQL subscriptions. It is not straightforward to monitor and analyze WebSockets with Apollo’s GraphOS platform.

Learn more about how Hasura gives you a scalable subscriptions API on Postgres.

GraphQL Federation

Hasura allows you to declaratively combine multiple sub-graphs such as databases, REST APIs or GraphQL APIs into a supergraph while maintaining the flexibility and modularity of the underlying services.

As GraphQL adoption spreads into enterprises, a federated GraphQL approach is needed to tame the sprawl while retaining team autonomy. Apollo has introduced and  evangelized the “supergraph” – a federated GraphQL architecture to help enterprises operate GraphQL at a larger scale. Apollo GraphOS is their platform for building, managing, and scaling a supergraph.

While Apollo GraphOS does provide convenient features (like Apollo Studio, Schema Registry, Apollo Router, etc.) for composing and managing the supergraph, it has some limitations:

1. Not declarative: You need to insert custom middleware code into your subgraphs to connect them into the Apollo supergraph. Check out the list of compatible libraries that are compliant with Apollo Federation specifications.
2. Heavy lift for non-GraphQL subgraphs: Apollo Federation is optimized by federating compatible GraphQL servers. While you can technically federate REST and non-GraphQL resources with the Apollo, it requires significantly more effort.
3. Does not account for the effort to build the subgraph Apollo GraphOS assumes your subgraphs are built and ready to go. It does not account for the time it takes to build a GraphQL for your sub-domain.

By contrast, Hasura's approach to GraphQL Federation is:

1. Declarative: You can declaratively add subgraph resources (GraphQL, REST, databases, etc.) to Hasura to get a federated API. Unlike Apollo, you do not need to make any proprietary modifications to GraphQL subgraph servers.
2. Multi-protocol support: Federation in Hasura is not restricted to just GraphQL. You can federate instantly across databases, REST APIs, and of course GraphQL APIs as well.
3. Instant GraphQL Subgraphs: Hasura gives instant GraphQL APIs over many popular data sources and can be used as a subgraph without any extra effort.

As discussed above, Apollo does not automate any of the GraphQL API creation, security, or performance optimization. It was not designed to. Apollo GraphQL is a good choice if you really need to manually develop a GraphQL server.

The common use cases where we see users choose Apollo over Hasura:

• You want to write new custom logic code in GraphQL (ideally, not recommended. You can use REST APIs and stitch them to GraphQL as well).
• Already have an existing GraphQL server manually built using Apollo Server and want to continue for maintenance.
• Hasura does not support instant GraphQL / API for your database.

In all other cases, you are going to be investing a lot of time and resources to build a custom GraphQL backends with Apollo.

If you are already using Apollo GraphQL, you have several choices to incrementally and gradually bring Hasura into the mix to enjoy some of the benefits mentioned above.

1. Hasura as a subgraph: If you are using Apollo GraphOS for GraphQL federation, you can feed a Hasura-powered GraphQL endpoint as a subgraph into your Apollo supergraph. Hasura will let you build new subgraphs much faster than building them by hand with Apollo or other DIY methods. You can also gradually port existing subgraphs to Hasura if the maintenance burden of those is getting cumbersome.
2. Hasura as a federated graph (supergraph): If you have existing GraphQL endpoints powered by Apollo Server, you can bring that in as a source via a Remote Schema. Hasura acts as a gateway of sorts in this case and lets layer on benefits like declarative authorization layer on your existing Apollo GraphQL endpoint.

If you are already using or exploring Apollo and want to learn more about how you can leverage Hasura, reach out to us for a custom consultation / demo.

Hasura’s biggest advantage over DIY GraphQL with Apollo is significantly lower time to market, with a smaller backend development team. By automating 50-80% of the time it takes to develop, operate, and scale a high-quality GraphQL API, Hasura allows you to build and ship products and features faster.

With Hasura, your developers can focus on innovating and building products vs. spending hours on non-differentiated work like writing CRUD code and resolvers.

Hasura also reduces your reliance on developers with deep GraphQL expertise, which significantly broadens the talent pool for hiring, but also lets you do more with the team in place.

Hasura’s compiler approach is architecturally more cost-efficient, which results in cost-savings out of the box. Similar efficiency and savings could be achieved with DIY GraphQL but with significant development effort.

Better ROI on GraphQL federation by using domain-first tools like Hasura

GraphQL practitioners who leverage domain-first approaches see significantly higher return on investment (ROI) for their efforts/spend: approximately ~10X vs. 1.5x with schema-first methods.

For a detailed writeup on a model to benchmark value from GraphQL and a study in contrast form these two approaches, please check out this post – Measuring Impact: A guide to the ROI on GraphQL

As with any DIY approach, you likely get slightly more control of the implementation assuming you have GraphQL experts who really know what they are doing. The question to ask yourself is whether you really need that level of customization, and is the resulting increased time to market, costs, and complexity worth the tradeoff?