"Object-relational mapping is a leaky abstraction leading to slow imperative code"

So they added REST on top of ORM, few more layers of data transformation and even leakier abstraction, so poor dev doesn't have to worry about "low level" SQL.

I lost count of how many different libs/frameworks i saw that exposed CRUD through HTTP, all failed miserably, because it is actually very dumb idea.

This is nothing like what you're describing.

Postgrest is not an ORM, it just takes rows from your database and sends them to the client.

It encourages you to write SQL. Write a decent SQL schema. Write SQL views on top of that schema to provide the rows to your API. Even write SQL functions to modify the data in reaction to client calls!

If you hate ORMs and love SQL (specially Postgres, because it's amazing) this is the tool you should be using.

Postgrest is RRM actually- rest relational mapper.

My point is - exposing db over HTTP (REST, GraphQL, ...) is bad architectural design and idea.

> My point is - exposing db over HTTP (REST, GraphQL, ...) is bad architectural design and idea.

I'm with you that exposing a fairly free-form query language over HTTP seems like something that's gonna bite several someones in the ass pretty hard at some point (GraphQL) but what's that got to do with PostgREST?

That's why one does not deploy postgrest alone but use it in a setting like this https://github.com/subzerocloud/postgrest-starter-kit

where you at the proxy level can say things like "return 400 if the client did not provide at least 2 filters for the table" or "allow filtering on column a and b because they have indexes but not on c"

But again, those are things to consider when you have datasets exceding hundreds of K or millions, you don't need to care about this when you have tables with 10s of Ks