4 ms·

I know this is asked before, but can someone concisely describe when you should use Hasura, and when Hasura is the wrong abstraction for your problem?

dmitryminkovsky 5y ago
In my mind, you shouldn't use Hasura when you can get away with Jamstack (ie static pre-compilation of your entire site, no backend at all). In those cases you can use other backends with less cognitive/operational overhead. For example, you could get away with using Airtable as a backend, or something similar. Hasura, on the other hand, is good for proper apps where you really want fine, control over a user-facing backend. Hasura makes that fine control easier to attain than ever, but you don't always need that.
- motleydev 5y ago
  Even in this context, Hasura could still be a great fit. If you have any form of existing database from the supported set in Hasura, then Hasura can still help by give you an instant read layer to that data. If you need to lock down parts of your data for the static site, or want to add a little bit of interactivity on top of the static site, or even if you just want to bring your own GraphQL layer to a tool like Gatsby - these are all great cases for Hasura still. It gives you super fast API access to existing data.
  - dmitryminkovsky 5y ago
    > Even in this context, Hasura could still be a great fit. For sure, but might be too heavy depending on the specifics of the use-case. "If you can get away with" was my main point.
- bpicolo 5y ago
  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.
maxcan 5y ago
There are plenty of exceptions to this, but as a general rule: Should: mostly front end app where your need a mostly CRUD style access to a backend with permissions that can be expressed using their DSL and are comfortable with all your back end logic being in lambda functions. Should not (and this is a stretch for me since I love hasura): a large high amount of idiosyncratic backend logic that you don’t want to but in lambda functions but want more of running app servers. For example, I wouldn’t put something like a Twitter or clubhouse clone on hasura. However, I may run some sub services on hasura.
- praveenweb 5y ago
  > with all your back end logic being in lambda functions. Although this is recommended for NoOps and Scale, you can technically run all your backend logic on any full fledged servers that can run anywhere. Hasura just requires a HTTP endpoint for custom logic.
- sorenbs 5y ago
  Many prisma.io users tell us that they use prisma to implement complex business logic and then stitch it all together in hasura which exposes the final graphql API. So it might even be feasible to use Hasura for more complex applications. I'm curious if there are specific reasons you see this not working well?
  - maxcan 5y ago
    Not really. I had to kind of steel man the anti hasura case since I overall agree with you.
ianpurton 5y ago
Low code tools like Hasura (and PostgREST) shine for database heavy applications with a single page front end i.e. React. In some cases you may be able to get away with no server side code.
motleydev 5y ago
If you have an existing (supported) database and your team has decided for the benefits of GraphQL, Hasura is a slam dunk. If you have a non-supported dataset, or abstracting your business logic to cloud scalable services would be cost prohibitive, you might not need Hasura. But the cost testing it out is super low since it doesn't alter your underlying data - unless you use the API to mutate your database, but that's sort of self explanitory there. :D
tango12 5y ago
(from Hasura) We want Hasura to be a self-serve API for your data, so that the API is entirely managed and as a developer you can focus entirely on your domain's data and logic. That said, we're not a 100% there for all use-cases and we'll keep evolving. Because it's possible to incrementally use Hasura along with your own API service, it doesn't have to be a binary decision to use in the stack upfront. (eg: use Hasura just for reads, or just for subscriptions, or just to trigger logic when there's a data change event aka CDC) Where it works well today: - You have data / functions in database(s) that you want to bring to your GraphQL API in a secure, performant way - You're able to bring in custom logic as stateless HTTP handlers that extend your API schema Where it might not be worth the trade-off today: - The API you're putting together has so much custom logic for each controller that you'd prefer building the whole thing yourself In practice, given that one can extend Hasura's API with one's own API quite easily, our users end up saving 50-90% of work they'd have to hand-write. The performance and authz benefit for that chunk is huge because it's out of the box and "managed". We're continuously working on making this easier and better so we can keep chipping away at that trade-off! Shameless plug given we have our annual user conference today: I'm doing a session on "How to think in Hasura" and "How to incrementally adopt Hasura in your existing stack" that might be helpful for folks thinking about when to, when not-to, and how-to. Link to talk here: https://hasura.io/events/hasura-con-2021/talks/architect-guide-to-building-with-hasura/ https://hasura.io/events/hasura-con-2021/talks/architect-gui...
- hashkb 5y ago
  I found it so awkward to configure authorization and to apply custom logic that I went crawling back to Rails to get my current project shipped. For me, the value of a graphql API just isn't enough to move me. Typescript all the way down isn't that big a deal. It's great on the frontend... but the backend wasn't broke. No need to fix.
  - tango12 5y ago
    That's fair. :) What were some of the authz pieces you struggled with?

dmitryminkovsky 5y ago

In my mind, you shouldn't use Hasura when you can get away with Jamstack (ie static pre-compilation of your entire site, no backend at all). In those cases you can use other backends with less cognitive/operational overhead. For example, you could get away with using Airtable as a backend, or something similar. Hasura, on the other hand, is good for proper apps where you really want fine, control over a user-facing backend. Hasura makes that fine control easier to attain than ever, but you don't always need that.

motleydev 5y ago
Even in this context, Hasura could still be a great fit. If you have any form of existing database from the supported set in Hasura, then Hasura can still help by give you an instant read layer to that data. If you need to lock down parts of your data for the static site, or want to add a little bit of interactivity on top of the static site, or even if you just want to bring your own GraphQL layer to a tool like Gatsby - these are all great cases for Hasura still. It gives you super fast API access to existing data.
- dmitryminkovsky 5y ago
  > Even in this context, Hasura could still be a great fit. For sure, but might be too heavy depending on the specifics of the use-case. "If you can get away with" was my main point.
bpicolo 5y ago
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.

maxcan 5y ago

There are plenty of exceptions to this, but as a general rule: Should: mostly front end app where your need a mostly CRUD style access to a backend with permissions that can be expressed using their DSL and are comfortable with all your back end logic being in lambda functions. Should not (and this is a stretch for me since I love hasura): a large high amount of idiosyncratic backend logic that you don’t want to but in lambda functions but want more of running app servers. For example, I wouldn’t put something like a Twitter or clubhouse clone on hasura. However, I may run some sub services on hasura.

praveenweb 5y ago
> with all your back end logic being in lambda functions. Although this is recommended for NoOps and Scale, you can technically run all your backend logic on any full fledged servers that can run anywhere. Hasura just requires a HTTP endpoint for custom logic.
sorenbs 5y ago
Many prisma.io users tell us that they use prisma to implement complex business logic and then stitch it all together in hasura which exposes the final graphql API. So it might even be feasible to use Hasura for more complex applications. I'm curious if there are specific reasons you see this not working well?
- maxcan 5y ago
  Not really. I had to kind of steel man the anti hasura case since I overall agree with you.

ianpurton 5y ago

Low code tools like Hasura (and PostgREST) shine for database heavy applications with a single page front end i.e. React. In some cases you may be able to get away with no server side code.

motleydev 5y ago

If you have an existing (supported) database and your team has decided for the benefits of GraphQL, Hasura is a slam dunk. If you have a non-supported dataset, or abstracting your business logic to cloud scalable services would be cost prohibitive, you might not need Hasura. But the cost testing it out is super low since it doesn't alter your underlying data - unless you use the API to mutate your database, but that's sort of self explanitory there. :D

tango12 5y ago

(from Hasura) We want Hasura to be a self-serve API for your data, so that the API is entirely managed and as a developer you can focus entirely on your domain's data and logic. That said, we're not a 100% there for all use-cases and we'll keep evolving. Because it's possible to incrementally use Hasura along with your own API service, it doesn't have to be a binary decision to use in the stack upfront. (eg: use Hasura just for reads, or just for subscriptions, or just to trigger logic when there's a data change event aka CDC) Where it works well today: - You have data / functions in database(s) that you want to bring to your GraphQL API in a secure, performant way - You're able to bring in custom logic as stateless HTTP handlers that extend your API schema Where it might not be worth the trade-off today: - The API you're putting together has so much custom logic for each controller that you'd prefer building the whole thing yourself In practice, given that one can extend Hasura's API with one's own API quite easily, our users end up saving 50-90% of work they'd have to hand-write. The performance and authz benefit for that chunk is huge because it's out of the box and "managed". We're continuously working on making this easier and better so we can keep chipping away at that trade-off! Shameless plug given we have our annual user conference today: I'm doing a session on "How to think in Hasura" and "How to incrementally adopt Hasura in your existing stack" that might be helpful for folks thinking about when to, when not-to, and how-to. Link to talk here: https://hasura.io/events/hasura-con-2021/talks/architect-guide-to-building-with-hasura/ https://hasura.io/events/hasura-con-2021/talks/architect-gui...

hashkb 5y ago
I found it so awkward to configure authorization and to apply custom logic that I went crawling back to Rails to get my current project shipped. For me, the value of a graphql API just isn't enough to move me. Typescript all the way down isn't that big a deal. It's great on the frontend... but the backend wasn't broke. No need to fix.
- tango12 5y ago
  That's fair. :) What were some of the authz pieces you struggled with?