4 ms·

My sense of Hasura is that it's great for CRUD prototyping, but every usage ends up requiring a more fully fledged backend in the mix anyway? Hasura can't impl

My sense of Hasura is that it's great for CRUD prototyping, but every usage ends up requiring a more fully fledged backend in the mix anyway? Hasura can't implement your business logic. If Hasura is my first-stage backend, that means I need to reinvent a lot of the controls it would provide anyway - auth, graphql APIs to integrate into it, etc - for the servers that can do that business logic. So it doesn't really feel like a choice between Hasura and a custom backend. You can have a custom backend, or both Hasura and also a custom backend. It's an excellent choice for killing off boilerplate CRUD, though.

dmitryminkovsky 5y ago
> Hasura can't implement your business logic. You can implement a ton of it in stored procedures and check constraints, which I realize some people don't like, but I really like a lot. But yes, there are limits to what you can do with this, and testing PL/pgSQL or whatever language you use for your procedures is prohibitively difficult. > but every usage ends up requiring a more fully fledged backend in the mix anyway? So yes, I agree, if you use Hasura, you will end up with a backend as well. This backend will run your auth (if you don't go a third party route) and your Hasura Actions[0][1], which I think is fine. > So it doesn't really feel like a choice between Hasura and a custom backend. You can have a custom backend, or both Hasura and also a custom backend. It's an excellent choice for killing off boilerplate CRUD, though. That's my take, too. Hasura totally kills boilerplate CRUD, adds the ability to do rich GraphQL querying, and my favorite feature—declarative role-based authorization/access control—puts the icing on the cake. [0] https://hasura.io/docs/latest/graphql/core/actions/index.html https://hasura.io/docs/latest/graphql/core/actions/index.htm... [1] https://stackoverflow.com/q/67053247/741970 https://stackoverflow.com/q/67053247/741970
- bpicolo 5y ago
  Data transformations are a small subset of business logic. Talking to microservices, third party integrations, and email, for example, are other pieces.
  - dmitryminkovsky 5y ago
    Right, you'd use your API backend and tie them into Hasura with actions if you wanted them tied to Hasura. Of course you can't have your whole app in Hasura, and I don't think they make that claim? Maybe they did before they added actions, but I think they knew that a bit bogus so they added actions and before that had remote schemas.
- devit 5y ago
  Why would testing stored procedures be "prohibitely difficult"? Just create a new test database, populate it with test data, call the function with test inputs and assert that the return value and the SQL dump of the resulting state of the database are what you expect.
  - dmitryminkovsky 5y ago
    That's a lot harder than unit testing, for me at least. When you have a small team (or a team consisting of 1 person :)) there are just so many other things you'll end up needing to do before properly verifying functions that "work."
- Dystopian 5y ago
  (From Hasura) Loved that you mentioned PL/pgSQL - consistently impressed by the amount of logic that can be implemented in database using that or plv8 or its cousins. I personally have feels about why that may be a good solution for a lot of small-to-mid-to-large size build outs. But yeah, in terms of logic we definitely expect you're going to need at least one other service for auth in the stack (for simplicity that service could also be used for any logic-based work as well). One of the things we pride ourselves on is being non-opinionated about the logic side of the stack and trying to create as many 'escape-hatches' as possible. Want to use db eventing? - We can event out to an external service. Setup a custom action? - We can toss those arguments out to an external service and return a response. Want to do some magic™ using other GraphQL tooling like Prima or Graphene? You can mesh those in with remote schemas. We really want to build a tool that helps onboard you into the GraphQL ecosystem, but then scales with you as your stack becomes more complicated.

dmitryminkovsky 5y ago

> Hasura can't implement your business logic. You can implement a ton of it in stored procedures and check constraints, which I realize some people don't like, but I really like a lot. But yes, there are limits to what you can do with this, and testing PL/pgSQL or whatever language you use for your procedures is prohibitively difficult. > but every usage ends up requiring a more fully fledged backend in the mix anyway? So yes, I agree, if you use Hasura, you will end up with a backend as well. This backend will run your auth (if you don't go a third party route) and your Hasura Actions[0][1], which I think is fine. > So it doesn't really feel like a choice between Hasura and a custom backend. You can have a custom backend, or both Hasura and also a custom backend. It's an excellent choice for killing off boilerplate CRUD, though. That's my take, too. Hasura totally kills boilerplate CRUD, adds the ability to do rich GraphQL querying, and my favorite feature—declarative role-based authorization/access control—puts the icing on the cake. [0] https://hasura.io/docs/latest/graphql/core/actions/index.html https://hasura.io/docs/latest/graphql/core/actions/index.htm... [1] https://stackoverflow.com/q/67053247/741970 https://stackoverflow.com/q/67053247/741970

bpicolo 5y ago
Data transformations are a small subset of business logic. Talking to microservices, third party integrations, and email, for example, are other pieces.
- dmitryminkovsky 5y ago
  Right, you'd use your API backend and tie them into Hasura with actions if you wanted them tied to Hasura. Of course you can't have your whole app in Hasura, and I don't think they make that claim? Maybe they did before they added actions, but I think they knew that a bit bogus so they added actions and before that had remote schemas.
devit 5y ago
Why would testing stored procedures be "prohibitely difficult"? Just create a new test database, populate it with test data, call the function with test inputs and assert that the return value and the SQL dump of the resulting state of the database are what you expect.
- dmitryminkovsky 5y ago
  That's a lot harder than unit testing, for me at least. When you have a small team (or a team consisting of 1 person :)) there are just so many other things you'll end up needing to do before properly verifying functions that "work."
Dystopian 5y ago
(From Hasura) Loved that you mentioned PL/pgSQL - consistently impressed by the amount of logic that can be implemented in database using that or plv8 or its cousins. I personally have feels about why that may be a good solution for a lot of small-to-mid-to-large size build outs. But yeah, in terms of logic we definitely expect you're going to need at least one other service for auth in the stack (for simplicity that service could also be used for any logic-based work as well). One of the things we pride ourselves on is being non-opinionated about the logic side of the stack and trying to create as many 'escape-hatches' as possible. Want to use db eventing? - We can event out to an external service. Setup a custom action? - We can toss those arguments out to an external service and return a response. Want to do some magic™ using other GraphQL tooling like Prima or Graphene? You can mesh those in with remote schemas. We really want to build a tool that helps onboard you into the GraphQL ecosystem, but then scales with you as your stack becomes more complicated.