[BenjieGillam]

It's not generally safe to expose SQL to untrusted clients. For example, PostgreSQL 12.2 was released yesterday and fixed a security issue where `ALTER ... DEPENDS ON EXTENSION` did not have any privilege check whatsoever. SQL is also not at all well suited for the needs of frontend web app developers - just ask Facebook about their experiences with FQL! Using an API that's more ergonomic for the frontend, such as GraphQL, backed by a language which is optimised for the backend, such as SQL, is the best of both worlds.

[markhalonen]

No idea why Benjie is getting down voted, SQL from a client is a bad idea, and writing billions and billions of CRUD endpoints is soul-draining.

Postgrahile is the best of both worlds, providing a nice GraphQL interface on top of your database.

If you decide you need to write crud endpoints, you have your database still. It's a zero-cost abstraction, which is wild.

[ltbarcly3]

Yes of course you cant allow uncontrolled sql execution, but an api that just maps to crud operations isn't good either.

[BenjieGillam]

Agreed: an API that _just_ maps to CRUD operations isn’t good. I’m not advocating for that, neither is singingwolfboy, and the starter repo he’s linked to basically does not use them: there are only 4 CRUD mutations, all the others are custom. I rarely use CRUD operations in PostGraphile, mostly I use custom mutations either defined in SQL or TypeScript.

[iamaelephant]

Counterpoint yes it is.

[ltbarcly3]

Not according to https://publications.opengroup.org/standards/soa

There is a lot of context lost in generalities so I admit you have to look at every specific situation, but in general CRUD means pushing business logic down to the client (which is generally some kind of code running in a browser or mobile app), which is the opposite of everything good in the world.