Hasura GraphQL - First impressions

Trying the realtime GraphQL API on Postgres from Hasura

Tl,dr: The GraphQL ecosystem is growing quickly, one of its' newer options to get your API going is Hasura. They provide a solid Getting Started experience, expose advanced data access and migration options via a nice UI and also have a great documentation.

GraphQL at its' core is a specification for data communication, most commonly used between clients and servers. Originally created and open sourced by Facebook, it quickly grow and got picked up by a lot of companies in all shapes and sizes. Nowadays there's a growing number of startups providing services in the GraphQL space. I've previously explored one of them, Prisma, and have written about their magic GraphQL tricks. Today let's take a look at another service in this space, called Hasura.

Hasura promises you a GraphQL API on existing and new Postgres databases, focusing on realtime features leveraging subscriptions. Hasura engines is strictly limited to Postgres, giving them the advantage to use these databases' features tightly in their engine. For example, instead of resolving each field separately, they transform the whole GraphQL query to a corresponding SQL statement. This helps to avoid unnecessary database request (ever heard of the n+1 problem?). The Hasura team described their architecture further some time ago.

Another key feature is Hasuras' console. This is not only a GUI to Postgres, it also lets you define what tables to expose in your GraphQL engine, add views, access permissions, event hooks and more.

All of this sounds promising to me, so I went ahead an gave Hasura a try.

_{^{Confetti for the GraphQL ecosystem. Photo by Pablo Heimplatz on Unsplash.}}

Getting Started

Hasuras' documentation, which is actually very good, has two Getting Started options described. There is a One-Click option to deploy to Heroku, which hosts your database, as well as your Hasura GraphQL engine there. The other one is to start locally in a docker environment. These option also allows you to easily host your production environment on a lot of different providers. I tried the docker way, which went really smoothly and started in only a few minutes.
No matter what you choose, your first step should be to open the console. That is under http://localhost:8080/console (or under your Heroku URL if you used that), check the docs when in doubt. Take a look around, this is where Hasuras' superpowers shine. I really liked their UI to manage my data. You have an embedded GraphiQL view to explore your API, a data tab to manage your database and more.

The first thing I did was to add a table under the data tab. There you can enter a table name, some columns and a primary key, click Create, and voilà. You not only created a table on postgres like that, you also now have your first types in your GraphQL schema! Check the GraphiQL tab. There are queries, mutations and subscriptions generated according to your table fields. That's impressive and powersome.

From there I created a basic author - post datamodel with some foreign key relations, which can be exposed as relationships for your GraphQL schema. Really nice, if you ask me. By the way, you can check out my experiments on GitHub.

There's also an option to add a third party GraphQL schema (schema-stitching for the win) and another option for exposing events to external services. The latter has a lot of potential, as it allows you to integrate any serverless functions to events happening in your database, and more. Again, Hasuras' documentation is very helpful!

Getting ready for production

Playing around in the console, tweaking tables and relations is fun, but how would we bring our progress from a dev to a production environment? Is there some kind of continous integration?

Luckily, Hasura has an answer in the form of migrations. You can choose to let Hasura log all changes made to the database schema, as well as the Hasura metadata, by using their provided CLI. Using this will generate some yaml files, which you can use to recreate your local dev database in a staging and production environment. This made a really good impression on me. Bringing your data to prod, check!

Next thing one might wonder about is security. The base line of Hasuras' defense is setting an admin secret. This locks the access to your managemnt console down and also enables you to set authentication and access rules. The latter again is a great concept. You can set fine grained rules for every field in your GraphQl schema within an intuitive UI. Preventing access to certain data tables? To certain fields in any table? Only allow to view entries created by the current user? Check, check and check!

Sadly, there are some disadvantages here. Right noe there is no option to guard your GraphQL API against malicous queries integrated. Think deeply nested or expensive queries. But they are working on enabling some options there. Also adding helpful third party tools to your GraphQL server is not possible, at least not directly.

So, what more?

Using the Hasura engine gets you started with your next GraphQL API server quickly. Honestly, I was surprised how seamless and quick it was. But at first it felt quite, well strange, to give the API creation out of my hand. This is something you have to overcome. Granted, you have some options to shape the API via access rules and custom views. Still there are some tools from the wider GraphQL engine which cannot be used directly. Right now, I would consider adding a plain GraphQL gateway server in front of Hasuras engine and delegate query execution from there to Hasura. That would enable using tools for rate limiting, as well as adding monitoring solutions like Apollo engine or anything else you fancy.

Other than that, using Hasura has some great benefits. Their tight integration with Postgres enables performant access to your data. Oh and did I mention they are not only free to use, but also complety open source? Last but not least, their documentation and learning options are great and growing constantly. That should be an important point when evaluating a new tech stack.

I'm eager to try them out in some feature projects of mine!

This article was first published on my blog