In my opinion GraphQL is operating on an entirely different level to SQL in one meaningful way: manipulating structured data

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.

There are existing frontend tools that can compose GraphQL but only string builders can compose SQL, AFAIK; it also seems to act as a "paper over the underlying database specifics" by using what seems to be MongoDB-esque criteria: https://github.com/dosco/graphjin/wiki/Guide-to-GraphQL#othe... meaning the consumer need not know the postgres-vs-mysql-isms (in theory, of course)

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

Also GraphJin is the only one built in Go and therefore can be used as a library within your own Go app allowing you to use it while also adding any business logic you might need.

The iql tool is pretty amazing for coding up a query and intro.

Because sometimes writing the equiv SQL can be a pain in the ass. Pagination is such an example. PostGraphile does a good job of it that I don't need to reason about it.

This is called PostgREST: https://postgrest.org/. Never used it in production, but PostgREST leverages multiple PostgreSQL features: row-based security, schemas, authorizations, etc. I quite like PostgREST, and I'd use it for internal stuff.

We used PostgREST in a project at my previous company, and it's the most horrendous thing imaginable. The project is a meme in the company and nobody wants to work on it, including its author (who decided to switch teams becaus of how much he hated it).

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.

I tried PostgREST for a small internal and it was a decent experience. I followed the following rules:

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.

This is basically the idea behind [Thin Backend](https://thin.dev/). Instead of exposing raw SQL strings we have a few high level functions to compose queries in a nice way and to do all kind of CRUD operations. These functions map 1:1 to SQL.

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.

GraphQL is the extra. It's usually a lot easier to reason about a graphQL query and the necessary data for a frontend component, than to write a one-off SQL query for the same purpose.

GraphJin does auto db discovery and hence builds a relationship graph which it then uses to write out a single efficient sql query for any Graphql query or mutation even nested ones. As GraphJin improves and uses new capabilities of newer versions of the db you get that for free. In the backend your query is compiled only the first time into a prepared statement and from then on requests pretty much go directly to db.

Check out some of the generated queries this extension [1] pumps out and you might have an answer.

[1] https://github.com/supabase/pg_graphql

oh boy we got to the point were we’re wondering why we need a „backend“ anymore