I looked at Hasura a while back, and to be honest I thought it was the antithesis of all the things I loved about GraphQL so I moved on. Perhaps someone can convince me differently?
The thing I love most about GraphQL is that serves as the perfect contract layer between the front end and the backend. A very productive development method I've used is to have the front end and back end teams agree on the GraphQL types (often times having the front end folks actually write the types), quickly mock things out, then have the front end folks go implement the front end and the back end folks provide the real resolver implementations.
The things I love about this is that it really simplifies and hides the backend details from the front ends. With things like Hasura, you are directly exposing your DB schemas to the front end, essentially tightly coupling them together. That has always been a recipe for disaster whenever a project gets sufficient scale or complexity in my opinion.
Again, it was a long time ago when I dug into Hasura, but this whole concept of "Directly expose my DB schema as GraphQL" is the exact opposite of what I love about GraphQL in the first place.
Do you really need to decouple frontend and backend in the first place?
Why not separating concerns instead of separating technologies? Tight coupling of UI with database but decoupling of e.g. admin UI/backend from end-user UI/backend.
I'm the author of a Node.js RPC implementation (https://github.com/reframejs/wildcard-api) and the idea is the exact opposite of what you are prescribing: highly coupled frontend business logic with database schema/queries. Makes things so much simpler, in my experience.
The thing I love most about GraphQL is that serves as the perfect contract layer between the front end and the backend. A very productive development method I've used is to have the front end and back end teams agree on the GraphQL types (often times having the front end folks actually write the types), quickly mock things out, then have the front end folks go implement the front end and the back end folks provide the real resolver implementations.
The things I love about this is that it really simplifies and hides the backend details from the front ends. With things like Hasura, you are directly exposing your DB schemas to the front end, essentially tightly coupling them together. That has always been a recipe for disaster whenever a project gets sufficient scale or complexity in my opinion.
Again, it was a long time ago when I dug into Hasura, but this whole concept of "Directly expose my DB schema as GraphQL" is the exact opposite of what I love about GraphQL in the first place.