Thanks for the response Steve. In general, I unfortunately don’t agree that this is a “convenience” feature or that this alternative you brought up is “flexible”.

This way of doing things is just so much more painful in terms of ergonomics we elected to instead escape hatch into raw SQL with a different library (Sequelize) in our case. Black boxing some of our business logic into views or RPC is just not something devs I work with are comfortable with. Having business logic live in the db like this just unlocks a whole new world of pain for people who aren’t used to it. Now I have a whole new class of problems too, now I have to have unit tests in the db with pgTAP and now I as a dev have to decide when and where this kind of logic should go in the db vs in the application layer and how to test it. In general I would really call this not a viable alternative at all unless there are some comprehensive design documents that say “do this stuff as RPC in the db because it makes sense to do it there, do this stuff in the application layer”. When I tried selling this ‘workaround’ in its current form to other devs in my org, they all balked at it.

Maybe I’m thinking about how Postgrest is supposed to work fundamentally wrong and all of this stuff is generally supposed to live in the db. But there certainly isn’t any guidance directing that in documentation currently. And in general I think if you want to advocate for a design where you split business logic between your application layer and your db there should be a plethora of examples where this has been done successfully, especially because that idea goes very much against how a typical developer thinks about system design.

It’s weird because I can do everything else in a “typical CRUD app” the nice way with Postgrest except this. It feels like the part of the codebases where I have to deal with this (and indeed, it comes up every time) is a constant wart in an otherwise pretty good setup.

Please don’t take this as me hating on Postgrest. I think it’s absolutely fabulous software and I am in genuine awe of what you have achieved. I can only aspire to have your work ethic and vision when it comes to this kind of stuff. I just want to help you see how myself and the devs I work with use it in real life and how they react to Postgrest in the context of using it when trying to make maintained business applications over years of time.

Thanks for the honest feedback!

There's definitely a lot to improve upon. Not only on features but in documentation as you mention.

I'll revisit this issue after launch week.