(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

(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...