Manipulating rows in SQL is easy but doing nested joins and trying to represent one-to-many relationships correctly in the response is non trivial. I would say you have to be good at SQL to leverage the DB to make structured data, returning tables and rows is entry level.
In GraphQL on the other hand, it’s seamless / entry-level to query for nested data and represent it really semantically, which is very appealing when doing presentational work (read: UIs, I suppose).
Therefore, the purpose of constructs like this is to allow those working on the presentational layer to be able to construct queries for semantic, structured data themselves with no requirement for SQL / backend expertise. This is a pretty meaningful improvement to unblocking development for both sides of the stack, in my opinion, and is why I apply Hasura everywhere I can.
Also, don't overlook the whiz-bang of the GraphQL introspection tooling -- it's super handy for just kicking the tires on something in ways that "dump the SQL schema to the browser" likely wouldn't do
The related pg_graphql posted a while back (https://news.ycombinator.com/item?id=29430720) actually mentions GraphJin positively, and talks about a bunch of competing implementations, although it's not one-to-one with GraphJin because it seems to support mysql whereas pg_graphql is of course a PG extension
I don't know if this was because of PostgREST or because all the logic was encoded in grotesque looking SQL that nobody understood (and changing some things requires dropping and readding things).
It is an extremely cool project, don't get me wrong, but it's one of those things that's "I know this already and I'll use it for a weekend/poc project to not deal with writing a backend" and not for something important. And again, I don't know if this was just poor usage or something that manifests itself in every project that relies on it. Also the DSL is very much it's own thing, so migrating away from it is painful, especially if you inherited the project and don't want to read the document. But again, sample size is 1, so it's anecdotal.
1- Don't expose your real database but expose a database consisting of view on your real database so you can refactor.
2- Wrap your bussines logic in stored proc to keep your sql readable
3- Use jwt for authentication
That said, I would not recommend it for a large scale application. I consider it, maybe wrongly, as the MSAccess of the backend.
We use a WebSocket connection to keep all queries fast. Auth is solved with row level security.
It's even in the name: The backend layer is just a "thin" layer over the database. Most of the business logic is then implemented in a "rich" client/frontend.