[esquire_900]

I've always wondered about this without trying it myself. Isn't this be something that looks ideal to start with, but as the project progresses and the edge cases keep stacking, you end up writing a complete middle layer, which effectively turns out to be your own framework?

[CuriouslyC]

Most of the edge cases can be handled using stored procedures on the database, which can be called in PostgREST using a generic '/rpc/<name>' endpoint. You can use foreign data wrappers to handle almost all the remaining edge cases, though that has diminishing returns in terms of time savings vs having a separate service as cases increase in complexity.

[lelanthran]

> Most of the edge cases can be handled using stored procedures on the database,

This is what actually turned my off about it when I used it for a small hobby project: the tooling around programming in SQL is absolute crap.

Expressing business logic in stored procedures is great in theory, but in practice only the very simplest business logic will be written as stored procedures, because anything non-trivial is impossible to debug, impossible to log properly and there is never a call-stack available when the inevitable runtime error/exception occurs.

If the tooling for writing, debugging, deploying and testing stored procedures were up to the level of what Turbo Pascal was in the 80s, I'd do it in a heartbeat.

As things stand, the only way to figure out bugs in the system is to visually inspect the stored procedure source code.

[xupybd]

I've seen a very complex payroll written in stored procedures. You're right about debugging, it's horrible. Once you get good at it there is an elegance to the solution but refactoring sux. Then there is performance tuning. You can get things so fast because you don't have to fetch from the db, you're already at the data source. You can also get things so slow as your loaded up on complex queries.

[CuriouslyC]

The tooling support definitely needs to improve. Postgres has support for emitting notices in stored procedures, but the lack of debugging is big a minus.

If you write code in PLV8 you can mock Postgres specific global variables to debug code using Node, and testing is pretty smooth with PGTAP. The deployment story is still something every shop has to reinvent at this point though.

[pvillano]

Complexity is often unavoidable. The question is where do you put it?

[nsonha]

> looks ideal

It's the opposite, this is a stupid idea by the sound of it, as it goes against what we've learned for decades in this industry. You yourself speculated what could be wrong with it, not exactly hard to see.

Who knows, it might be great once you actually do it, but honestly I dont think so.