I've been making PostgreSQL-centered web apps for 9 years that way, by having PostgreSQL just return JSON. Then the "controller" (Ruby or whatever) parses the Mustache or ERB template with the JSON and returns HTML to the browser.
What I'm doing differently now is having PostgreSQL parse Mustache templates directly!
So now the controller just has to pass in the HTTP params, give it to the PostgreSQL function, and it returns HTML ready to return in the HTTP response.
It's not new, my first job circa 2007 was working on a Delphi 7 desktop application and all the "business logic" was stored procedures in an Oracle db. It was early in my career but I believe this was fairly popular in the early 00s. I was too young to have an opinion but for sure others will remember and be able to add more colour to it.
I haven't had the "pleasure" to work with stored procedures,etc but from conversations the main takeaways seems to be:
1: cooperation, nowadays database instances are cheaper and with Docker we can spin them up but having them shared doesn't feel like a fun thing when developing (triggers more than stored procedures here)
2: version control, kinda ties to the above but being able to keep track of changes (and related then to code being out of sync even if that would matter less in a application-less world)
3: debugging in general ?
4: debuging "spooky effects at a distance" when triggers,etc run.
> 2: version control, kinda ties to the above but being able to keep track of changes.
We dont use stored procedures at work, but all other database changes like tables, triggers etc. are committed to git and deployed using github actions. There's no need to run the sql manually
Oracle has a nice way to bundle stores procedures in packages, which makes large amounts of stored procedures manageable. So still ahead of Postgres, but Postgres is definitely good enough.
Asking from ignorance - are schemas not enough to replicate this most of the way? What are the extra nice to haves that would bring PG on par with Oracle here?
In my first proper job, I worked with an accounting system in 2014/2015 that was a .NET GUI client that directly called SQL Server stored procedures. There was a bundled WMS that did the same thing. IIRC the requests were sent directly to the database and were authenticated with the client user's details.
I was a data analyst and had full access to the database for reporting and data import/export purposes. I had a lot of fun browsing through the stored procedures, which were not locked down or encrypted in any way, and figuring out how it all worked.
I even fixed a bug with a custom module that was causing huge stock valuation errors (I can't believe I even did this now) and also created my own automated order import procedure by monitoring the procedures used by the client's order import screen. Possibly invalidating warranties and support contracts etc. but no problems came of it. They even tried to rehire me a few years later.
There's nothing wrong with it. Stored procedures, Java, Delphi, Ruby, Python, or whatever can be considered as a business logic layer separated from the data storage. Similarly, you consider your Python controller business layer separate from the web UI frontend.
And if you complain that stored procedure language is not so versatile for the business logic, remember that people have been using far worse languages for that, like COBOL, MUMPS, ColdFusion, ...
Despite reading the README and the article I am still unclear about how these templated values are populated. So presumably we store our HTML on the sql server along with some templating syntax then how do we plug that value so to speak?
Secondly, what do we do about things like HTML fragments à la HTMX / Datastar hypermedia approach? Do we just hit the DB for 10 lines of HTML to populate the next card in a multi step form?
Thanks for your response. I didn’t explain myself properly.
Suppose I have a html template that contains the dynamic value {{ foo }}, that template is on my SQLDB, how do I populate {{ foo }} whilst querying the template table?
For someone who wants to tread this path, using postgreSQL stored procedures in a team settings, what would be a good dev workflow in a team. Update them in git and use a CI to update the DB etc? Is there some tips that you can share on that?
For the big idea, see https://sive.rs/pg
I really took Rich Hickey's "Simplicity Matters" talk to heart. https://www.youtube.com/watch?v=rI8tNMsozo0
I've been making PostgreSQL-centered web apps for 9 years that way, by having PostgreSQL just return JSON. Then the "controller" (Ruby or whatever) parses the Mustache or ERB template with the JSON and returns HTML to the browser.
What I'm doing differently now is having PostgreSQL parse Mustache templates directly!
So now the controller just has to pass in the HTTP params, give it to the PostgreSQL function, and it returns HTML ready to return in the HTTP response.