What is Hasura

Hasura is an application which gives you an instant GraphQL/REST API based on your database schema. As of writing it supports Postgresql, SQL Server and Big Query databases but MySQL, Oracle and Elastic are also in the pipeline. You can use it for a rapid prototyping as well as production deployments as it can be scaled horizontally and has very good performance characteristics. If you are wondering - it is written in Haskel, and it’s very likely it will run much faster than your regular Django app.

Over the past few years, it has enjoyed a lot of adoption in the industry ie. Walmart, Atlassian, Netlify to name the few.

At Bravelab we believe it will play an important role as one of the tools improving development and time to market speeds. In fact Hasura team estimates that adopting it cuts down on development time by 50-80% according to their studies. Anything that’s saving you that much time is worth a try, right ?

How do you develop an application with Hasura - aka where do I put business logic ?

This is usually the first question - after all we are used to writing a lot of code. Hasura’s philosophy sits nicely in line with my personal view of how we should be writing an applications:

  • Assume you can do it in SQL unless proven otherwise. Your logic should be as close to the data as possible. This simple assumption eliminates a host of problems, and those who have experienced them know them very well. No round trips, no 1 selects, no stale data, no cashing problems, no date/timezone aware code to write - the list goes on. This comes down to using SQL functions, procedures, views, materialised views, triggers, different column types (like json, array), extensions and indexes. So by utilizing functionality that is already build in your database Hasura can take full advantage of that by exposing procedures or functions as fields in the GraphQL schema.
  • Delegate standalone functionalities to separate libraries, services, cloud functions. When you are dealing with oauth2, registration, data import, payment systems etc. these are usually present in every app. So you can write this functionality once and reuse. If you expose it on the backend or lambda function you can use Hasura Actions/Remote Schemas to proxy the requests to these services.

Example of a simple backend integration

On the django side let’s write a simple django view which will return json data.

json to django

We also need to expose this view in urlpattrens


On the Hasura side we need to define a custom action with request and response types.

type query
Type configuration

Now we can proxy the request to our backend service.

webhook handler

What about deployment

Deploying Hasura usually consists of two stages. Firstly, we need to export our local configuration to yaml files. Once you’ve crafted the exact setup you can use gui or command line command for exporting ie.

hasura metadata export

This will create a directory in your project called metadata. You should version control this directory just as in your django project. Then to apply this configuration on a remote hasura instance you need to run

metadata apply


metadata apply

This could be run as github action or on your local machine. As an example we have created very simple github action that deploys checked in files to the remote hasura node.


Why we’ve decided to use it

At Bravelab, we really care about delivering the best solution in the quickest possible manner. Over the years, we have been crafting API’s and backends by hand but with the arrival of modern no-code tooling like Hasura it’s becoming more and more apparent we want to be solving problems and not reinventing the wheel. We have chosen this solution because with a bit of configuration it takes away all these repetitive tasks from developers and let them focus on more challenging aspects of the project. Also for our clients it’s a great tool for integration with perhaps legacy systems and payment gateways. Overall our experience of using it has been great so far!

Want to get in touch? Drop us a line!