4 ms·
I settled for Hasura in a prod app after trying Postgrest, Postgraphile and Strapi. I believe its a permanent addition to my stack. The main reason for me was
by shivekkhurana 7y ago
I settled for Hasura in a prod app after trying Postgrest, Postgraphile and Strapi. I believe its a permanent addition to my stack.
The main reason for me was RBAC. Converting db-to-api is not that hard but providing access control almost always requires some form of middlewares. Hasura does RBAC very well.
Another feature that I haven't deployed but find useful is webhooks. You can trigger webhooks as your data changes.
I do need a server to handle object storage, email and cron so it's not a 100% there, but I can see the appeal of rapid APIs at low cost.
Also subscriptions are <3.
All the best to the Hasura team.
- markhalonen 7y agoWhat made you choose Hasura over Postgraphile? RBAC is a postgres feature, not sure if that would affect the decision?
- aidos 7y agoNot the parent but we went with Hasura over postgraphile because they do RLS outside of the dB. It allows them to load the data for all clients subscribed in a single query. Also the subscription story is better (from memory).
- shivekkhurana 7y agoWith Hasura, you can create arbitrary roles (like admin, manager, etc) and restrict access to data on the basis of these roles. These roles can be assigned to a frontend session by generating signed JWTs. With Postgres RBAC, you'd need something to lift the roles to be consumed by the frontend. With Hasura it works out of the box. Also, I did consider using Postgraphile, but it was easier to get started with Hasura, so I went ahead with it. I don't have enough info to make a comparison.
- tirumaraiselvan 7y agoYou might like our upcoming Scheduled Triggers feature which lets you invoke webhooks according to cron or adhoc timers: https://github.com/hasura/graphql-engine/pull/3553 https://github.com/hasura/graphql-engine/pull/3553