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 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.
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.
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:
https://gist.github.com/GavinRay97/d7b8805078a47e00001e58eb8...
I would be interested in hearing what problems you had and seeing if there isn't some way around it, just for my own curiosity.
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?
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.
What benefits would be using the DB over a GraphQL API?
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 :)
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.