How Hasura saved us a lot of time

Hello world! I’m Jérôme, software engineer at Maki. Today I want to tell you about our journey with Hasura and how it saved us a looot of time (like a lot!) building our product. If you have never heard of Hasura, don’t worry, I will present to you this amazing product! However, I will not detail all of Hasura’s features in this post but feel free to have a look at their documentation.

Disclaimer: this is not a promoted post. We only wanted to share our love for this product that helped us a lot. At the beginning of Maki, we would have liked this kind of post about it to help us decide whether it is worth trying or not!

So, what is Hasura?

The Hasura’s catchphrase speaks for itself:

Instant GraphQL & REST APIs on all your new and existing data to power modern apps and APIs

Working with PostgreSQL, SQL Server, or BigQuery? Then you just have to deploy the Hasura GraphQL engine, with access to a database to store its metadata, connect your database, and boom, a full GraphQL API! (At Maki we use GraphQL, so in this article, I will obviously focus on the GraphQL part, but keep in mind that having a REST API is possible!)

Hasura is open-source, but there is also a fully managed cloud version. It also comes with a console that provides a GraphiQL interface and all you need to manage your data and some more features we will speak about later!

Hasura’s console

Working with MongoDB? Stay with us! Hasura for MongoDB is coming soon!

Let’s take a step back in time

Maki day one. On the backend side, we are three former engineers from Everoad. Our brief is to build a SaaS in 100 days. Needless to say, we have little time. So let’s build on top of our expertise. At Everoad, we were working with a CQRS (Command and Query Responsibility Segregation) & Event sourcing patterns. It is powerful, we liked to work with it, but the initial setup is quite heavy and time-consuming. Also, it may be over-engineering. What should we have been decided? 😥

Thankfully one of us had heard of Hasura and how powerful it can be. So we decided to dig a bit to find out if it is so powerful or not (and saved us our free time).

Guess what? It did!

We built a proof of concept with our newly designed database. We were absolutely amazed by the GraphQL API automagically generated by Hasura.

CRUD basics? ✅

For every table tracked by Hasura, you will have an insert, update and delete mutations available. Also, you will have the choice between inserting one or many. Same for the update and delete, you can choose the by_pk (by primary key) mutation.

CRUD with nested objects? ✅

Aggregations? ✅

Role-based Authorization? ✅

You can set role permissions directly from the console. For each role, you can fully customize the permissions on each table.

In this example, users with the recruiter role cannot query auth_partner_id field.

A smile on our faces? ✅ 🤓

If we had to build it by ourselves, we would have taken shortcuts. By shortcuts, I mean not implementing all CRUD possibilities at the beginning. Which can lead to technical debt. Also, Hasura is optimized. Would we have had time to optimize everything to the maximum? To be honest, I am not sure. More technical debt.

We can now focus on business-oriented tasks

As Justin wrote in our previous article:

We can focus more on our product and on what we really want to bring to our customers in the end.

Starting from now, our main focus will be the business. Do you want a strong product based on Hasura? Take as much time as you need to design a strong database schema. Once it is done, you have nothing to worry about (at least for the API part).

You can focus where it really matters in the end, on the user’s satisfaction.

Going further with Hasura

I just highlighted what is in my opinion, the more time-consuming part: the GraphQL API. However, Hasura is much more than that.

First, it is easy to work on it with your team thanks to the migration files.

Hasura can manage your database schema for you. For instance, if you update your “users” table, Hasura will automatically generate “up” and “down” migration files.

Think of it as a git branch. Your teammate has just pushed a schema update. With the up file, you can apply this update. Only a feature branch and you want to discard this update? Use the down file.

Newcomer? Just pull the project and apply migrations files. There you go, a brand new database schema. Ready to build.

Hasura also offers the possibility to trigger events. For instance, you can execute a function on an update of a specific field. You can also use scheduled triggers with crontab or one-off scheduled triggers.

There are also the Hasura’s actions:

Actions are a way to extend Hasura’s schema with custom business logic using custom queries and mutations.

You can now, querying the same GraphQL endpoint, reach your backend server to handle specific business needs. Set the action’s webhook handler, and every time you query your action on your GraphQL API, it will query your webhook handler.

The last feature I want to highlight is the possibility to merge a remote schema to your Hasura GraphQL API. By remote schema, I mean another GraphQL API that is already live. With that, you can query both schemas on a single endpoint. Cool isn’t it?

Last words

I hope this article has piqued your interest in Hasura. You should definitely give it a try and you can be sure that it is production-ready. 👍

Also, let us know if you want more information about Hasura in a future article!

And if you are more on the frontend side, and have reached the end, first of all, bravo! And be sure to stay tuned for our next article: Maki Frontend Architecture: go far for less.

By the way, we are recruiting at Maki, wanna play with Hasura or simply help us to build the future of HR? See all our open positions.