So hasura just exposes a Postgres database through GraphQL?
That sounds kinda nifty, but does it then allow you to write custom code to add business logic? Glancing through the documentation, that part wasn't clear to me.
That's one of the most common misconceptions about Hasura.
While it CAN expose an existing Postgres database, where it really shines (in my opinion) is when you're starting a brand new product. Because you can create your whole database and all the relationships, foreign-keys, triggers, permissions, etc through the web console UI incredibly rapidly.
And yeah, it takes care of all CRUD and provides an aggregation/statistics API (sum, median, standard deviation, count, mean, variance, etc), and it leaves the pieces of custom business logic up to you to write. It's entirely agnostic to what you use to write these, so long as they expose an HTTP endpoint.
I really want to like Hasura, but very quickly you'll run into limitations of its permission system. Especially when dealing with logic across relationships.
If only Hasura supported some king of Prolog / Datalog instead of their ad-hoc JSON language, then you'd be able to write nearly any possible use cases. Until then, I'll stick to building and maintaining my own backends... manually :(
One of the biggest pain points I found was modeling Organization/Team/Multi-Tenant based permissions.
Generally, the advice is to use a session variable like X-Hasura-Organization-Id to filter in permissions, but recently through a Discord conversation a means to do this without a session variable was found out and I took some time to publish it as a Gist:
Right, those are the kind of permissions I had trouble with. That gist works for reads based on membership (even if a little unintuitive), but I couldn't figure out how do writes that validate using roles & permissions.
If you’re looking for more flexibility than Hasura, I’d recommend you try out Warthog (disclaimer: I’m the author). It’s a Node Library that uses TypeORM, TypeGraphQL and some extra magic under the hood to let you spin up APIs very quickly (auto-generated schema), but you also have access to the bare metal code. You can set up CRUD essentially free, but it provides you a slew of ways to handle more complex scenarios.
Sorry, I'm a bit new to GraphQL. Can you explain why this is more existing than starting a brand new product using plain PostgreSQL?
Can you also explain how locked in you are, if you decide you want to migrate away from Hasura, or in general want more flexibility that the use-case of Hasura + ForestryAdmin?
With plain PostgreSQL you have to write your own backend logic to access the database. The whole point of Hasura is exposing your DB via a GraphQL API with some bells and whistles (like authorization).
About lock-in... it's open source software, so you're as locked in as you'd be with, say, Rails or Django. It doesn't do anything special to PostgreSQL so you can always rewrite the API later from scratch, or build something else on top of its GraphQL API.
With some frameworks (i.e. ASP.NET core) you already have authentication and authorization middleware if you need them and you can use an ORM to map data objects to tables and query the DB with ease.
What benefits would be using the DB over a GraphQL API?
Well, not having to implement and maintain anything is a huge plus, especially when you have a large number of tables :)
Also, Hasura has some bells and whistles that would be a bit of a PITA to implement using traditional MVC frameworks, like per-column authorization, and, of course, the GraphQL to SQL translator.
> What benefits would be using the DB over a GraphQL API?
And I'd say that the biggest advantage of GraphQL is allowing customized payloads.
Say you need a list of users ids + emails in one page, and a list with ids + names + emails in other. In REST you either need to waste some bytes, have two endpoints, or use some conditional to show/hide the field.
With GraphQL you just have to ask for the fields you want.
The same applies to joins: you either add extra endpoints, extra logic, or the user has to make multiple requests. With GraphQL you can have custom joins.
Btw, if you still don't think that GraphQL is an advantage to you, I recommend checking its cousin-project PostgREST :)
> does it then allow you to write custom code to add business logic
Yes! Like gavinray said, you can create HTTP services in any language of your choice. Hasura can then be configured to call HTTP endpoints when something changes in the DB. And your services can call Hasura anytime of course.
Remember that Hasura handles all the authorization for you, so there's no need to "proxy" requests made to it.
You end up writing very little compared to traditional frameworks.
That sounds kinda nifty, but does it then allow you to write custom code to add business logic? Glancing through the documentation, that part wasn't clear to me.