You use an api-gateway in front of this and send those requests to your application server, generally though you should try to keep your business logic in triggers and stored procedures.
How long has Postgres been around? How long has your currently fashionable front-end framework been around?
I avoid triggers but put as much of my applications into stored procedures as I can.
If we then take your argument and instead just apply it to, say, using JS on the backend.. well, JS is not going anywhere any time soon.
pl/pgsql is absolutely awful and it is a disservice to other programming languages to call it a programming language. Writing actual, complicated business logic using this and maybe some mix of JS(because why not pull that into the databse?? great idea) is just going to make every single person who has to maintain this in the future hate your guts.
I'm truly glad I don't have to work with anyone who genuinely thinks such a design would be a good idea.
the comment makes sense if one interprets "frontend" as "all the shit in front of the database". which is a reasonable interpretation in the context of something like postgrest, if not perhaps satisfying to you.
> pl/pgsql is absolutely awful
who cares
> Writing actual, complicated business logic using this and maybe some mix of JS(because why not pull that into the databse?? great idea)
there are a number of other languages available for writing postgresql procedures, and you can add new ones
For data-heavy apps with very complex schemas, your code can actually get more readable inside stored procedures. I used procedures for a content creation pipeline/headless CMS app that had flexible workflow templates (those also lived in the DB). It works quite well, and is simpler and more readable than most common backend code and much faster to develop.
If you need to trigger async stuff, like network access or data processing, one pattern I enjoy is writing to a log-ish table that gets picked up and processed later by a separate service. This is nice for emails and other types of notifications: your users get a log of sent emails, and you can very easily do it inside a transaction.
If the complexity is on the querying side, then you can get a lot of mileage from views. If you need caching for that, materialized views really help.
However: If you're doing complex numeric/algorithmic stuff, rely on external libraries, or has just plain too much business logic... then doing things in a separate service is definitely better, no question about it.
Triggers, I'm personally not a fan.