We’ve been developing Mobile and Web applications for more than 6 years now and it has been our constant endeavour to improve our efficiency and increase the ROI for our clients. To make application development faster, we’ve invested in automation and technologies such as Heroku, DevOps, MobileOps, GraphQL, Flutter, Hasura, and more.
Using a combination of such tools helps us achieve our goals faster, make the product more robust, and increase customer happiness. Over the past year, Hasura has been an integral part of our development efforts and I hope it can be for you as well.
In this article, I will cover the following:
Modern applications today are becoming increasingly complex. They are real-time, interface with other internal and third party applications, expose public APIs, and their APIs are consumed by Mobile as well as Web Applications.
Hasura is in brief — API as a Service. Hasura sits between anything which interacts with your application and serves to automate a huge chunk of developer work.
Built with a vision to be a bridge between different data sets and the clients that consume those APIs, Hasura even pre-dates GraphQL (a query language for APIs). Creating APIs in many cases is sem-repetitive and error prone.
Using Hasura, you will be able to ship APIs faster and reliably. Enterprises and Startups need to move quickly and efficiently — Hasura enables us to do that.
For the first two clients with whom we used Hasura, we saved over 30% of backend development efforts - in some cases upto 50%
Thus, Hasura can automatically expose APIs by connecting with different databases, internal APIs as well as external APIs with minimal configuration. One can just start creating tables in a PostgreSQL Database and the corresponding GraphQL APIs will come to life automagically!
While the basic premise of Hasura is creating APIs from an underlying database, there is much more going on under the hood. Let’s discuss some of the key features of Hasura:
Hasura offers a hosted service as well as can be run on a docker container which you can host on any infrastructure provider such as AWS, GCP, or DigitalOcean. My suggestion is that you should use Hasura in the same network as your Database.
However, if you go with the Hosted Solution make sure you’re near the five eight geographical areas: Mumbai (India), Singapore, Sydney — New, Montreal — New, London — New, Frankfurt (Germany), Ohio, North California (USA)
If you’re an enterprise — I highly recommend the enterprise, self-hosted version of Hasura and if you’re a startup looking to save every dollar, go for the self hosted solution.
Either ways, you should be up and running in no time!
While this is not technically true for Hasura enterprise, their open source code and the self-hosted solution have the same engine running under the hood.
With a self-hosted application, you will be responsible for it’s DevOps, upgradation and security. Those who want to focus only on application development should not consider hosting it themselves to save a few bucks.
At SoluteLabs, we have a small DevOps team so we’re able to manage the same internally for most startups.
Hasura works with all languages, since you interface with Hasura in the form of JSON APIs, on the client side there is no barrier as such. At SoluteLabs, we’ve used Hasura APIs to be consumed from ReactJS front-ends as well as Mobile apps built with Flutter.
Any framework, as long as it speaks GraphQL would be able to interface with Hasura.
Probably the best selling point of Hasura, it makes API development very fast. Most applications, especially enterprise ones require a lot of data storage and transfer with high accountability and reliability.
One can think of Hasura as a low-code solution to create CRUD APIs which account for a bulk of work for backend developers in many cases. Once set up, developers can start creating tables or even interface with an existing database to create APIs with minimal configuration.
Also, we saw that Hasura connects not only with Databases but also internal and external APIs. Hasura evaluates and optimizes which API to call in real time, in a sense it’s a JIT compiler.
Hasura avoids N+1 issues completely (common with GraphQL implementations) and does memoization aggressively.
While this might sound a little alien to you, N+1 issues have been common with ORMs (Databases) for a long time. You can read more about it on the web.
Also, for those who don’t know, memoization is the process of storing and caching the results of expensive function calls. So if an API hits Hasura, it would ideally know which data source to connect to so that it can deliver results quickly.
Hasura, with its inbuilt engine, provides built-in authorization for your APIs and in my opinion this is where the small learning curve really starts.
We’ve all seen and heard about data breaches, S3 leaks and more. Applications today have APIs that are consumed by different kinds of developers — some creating internal apps where some might be consuming public APIs.
Hasura’s engine let’s developers set the right rules at the model level — this allows great flexibility on the developer’s end — they can set up rules that restrict users to see specific models, view certain parts of the models and even other models through relationships.
Therefore the security enforced can be brought down to the Row Level. While certain databases do offer this, Hasura brings it to an application layer instead of the database layer.
FYI - Hasura doesn’t provide an authentication service since most organizations have their own central systems setup. Hasura does integrate with all major auth services such as Auth0, Firebase Auth, Azure AD, Okta, etc.
As I discussed above, applications today have APIs that are consumed by a lot of third party applications. And there are many cases in which the same APIs are called multiple times which makes the downstream operations repetitive. It’s like asking for the same thing a million times.
In order to reduce the load on the server, developers generally resort to different caching mechanisms. Hasura caches the API response for queries and returns the results without ever making a trip to the database/downstream APIs.
Since Hasura is directly connected to the database, it can automatically detect any change and invalidate the cache whenever required. This makes it very effective and performant.
Hasura can connect to your database and create a real time API for your end customers. Any data change is reflected in real time and instead of a pull mechanism, the end client is notified of any change on the Database end.
Think of a Twitter feed, everytime someone makes a tweet — the end client can be notified of new tweets to show. If you had an application requiring and kind of such real time data, Hasura can get you up and running in no time.
For a client whom we are working for, we reduced our time in creating a live feed by more than 50%
The application is not able to just do this quickly, it can do it efficiently with a reducing burden on the backend database. You can read more about live queries on GitHub.
While there are less issues with versioning when it comes to GraphQL, there are still times when you want a different variant of your API to see the underlying metadata change or even slowly rolling out changes in any API to different users.
Hasura enables both the above scenarios so you can manage your CD/CI operations easily.
As it might be evident, Hasura can help automate a certain amount of APIs, take care of caching and even provide some functions such as Subscriptions which are otherwise time consuming to make.
Hasura in my mind is akin to DevOps which brought the Development and Operations team together. Hasura, in a sense, brings the backend and the frontend developers together wherein the frontend developers have more visibility into the operations
Frontend developers are usually accustomed to getting a postman collection from backend developers which makes their life easy. They’re generally not concerned with what goes in the backend, or what tables are there in the database for how the data is coming in from other data sources.
Bringing this transparency also increases the work for frontend developers. A boon and a curse in itself, Hasura forces the frontend developers to think beyond the present screen that they are developing.
To alleviate this, we had our backend developers create postman collections for the GraphQL APIs that the frontend developers would then consume.
Overall I would say that our backend efforts were reduced by at least 20% in complex applications and more than 30% in applications which had more storage and retrieval such as enterprise applications. If you extrapolate this to a year of work, a significant chunk of time and cost can be saved.
Hasura initially started with support only for Postgres databases, but has now extended support to MySQL as well as Windows Server. Looking at the way it is structured, Hasura cannot be used with NoSQL databases.
There is also a bit of a learning curve when it comes to creating the metadata and the authorisation techniques, but the effort involved will pay off within just one project. At SoluteLabs, we have been able to provide competitive quotes and excellent ROI for our customers because of Asura.
Self hosting Hasura is advisable only if you have knowledge of Docker or if you have someone who knows devops. If you’re on your own, I would really suggest that you go with the cloud version of a Hasura.
Having used Hasura in a few projects, I feel that there are a few drawbacks which you might have guessed from reading this article. Some of them being:
But overall, a solid recommendation from me and the team @SoluteLabs