Hasura isn't perfect

Nothing is perfect. I’m a big fan of Hasura.
Today I tried to migrate a slow, inefficient app using Rails backend to Hasura. I have used Hasura for a few months, understand how things work, and suppose the transition should be easy.
First, we need to understand what Hasura is and ignore all the fancy words that we see on landing pages, those words bring no understanding at all. Their purpose is for fucking business.
In the simplest form, Hasura is a black box that takes the input of GraphQL query/mutation, transforms those into raw SQL statements, executes them in the database, and responds to the client.
The official definition says Hasura is an engine, yes a fancy word to me, but it blurry for newcomers who don’t have any idea what is an “engine” stands for. Hopefully, my previous definition make it clearer to understand.
We can understand Hasura is just a transformer, nothing else. This is the most important matter.
WHY?
If you have any plan to migrate any existing system to Hasura, please be aware something. I’m sure that migration to Hasura is the best experience among other solutions, it doesn’t like anything else in this world, but it still has some caveats.
First, It’s NOT a magician
I know the Hasura’s capability, they offer remote joins, actions, and more. What I want to mention here, don’t expect we can completely remove backend code because we have Hasura powerful features, hell no.
WHY?
Because it can’t do something that SQL can’t do.
We all know that in our system, there are logics that can’t just be covered by data structure and simple SQL joins. We need code, for sure, and Hasura just takes it with an easy approach: it lifts all heavy SQL related for you, you need to take care of the application logic. Hasura layer is NOT the application layer.
I love this the most, because understanding data structure is important, but spending time, and remembering language syntax to write a correct query is a damn shit, a waste of resources and developers should not do that. In this AI era, we can see it clearer than ever. Hasura takes this heavy burden out of developer's mind, we should focus more time on the real valuable problem: logic.
That’s why Hasura makes the backend development extremely fast, and easier, with no code to maintain. And especially free from very low-level problems.
Second, it’s just SQL, so many nested objects…
Well let’s take a very simple in the backend code, it returns an object like this
{
"post": {
"id": "post-1",
"author_name": "John Doe"
}
}
(Sorry “John Doe”, I don’t know who you are but people keep quoting your name)
We have table post, table author, you know. Where is the author_name
value from? Yes, you’re right, it comes from the author
table, and it means there is something in the code where we do something like this
const author = await getAuthor();
return {
author_name: author.name
}
In Hasura, we can’t just do that because it’s the backend code, NOT SQL ability, the query result should be something like
{
"post": {
"id": "post-1",
"author": {
"name": "John Doe"
}
}
}
If we like to keep the previous response structure, we need to use compute fields, or something else, much more complex and isn’t worth the time to do in my opinion.
Do you feel it’s ugly? Well, it depends. I won’t say it’s either pros and cons. When you look at the later response structure, your mind will immediately say “The author is from another table”, you know the behind data structure, while for the first one, you don’t know what is the real story.
In my experience, I will prefer the latter approach, and changing the “transform layer” on the frontend code. I DO think, having a transform layer in the frontend is a good approach because it makes frontend isolated, and stable regardless of the backend system. Using direct values from the backend in the frontend is shot into your foot.
Final thoughts
There is something more with the Hasura journey. I’m still on track and Hasura is one of the tools that make me love web development.
There are 2 approaches for development nowadays: using Hasura, and the rest.
Subscribe to my newsletter
Read articles from ShinaBR2 directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

ShinaBR2
ShinaBR2
Enthusiasm for building products with less code but more reliable.