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.
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?
This is great stuff. I fell away from web dev for a very long time because I have always been a developer who focused on building from the database first and outwards while using very light amounts of business logic. This feels very old web and I encourage others to try this approach. The lightweightedness of the approach is the beauty of it and you will get much, much better at your database language of choice.
Business logics in PostgresSQL? Impressive, never think of using it this way but it looks actually pretty good! Last time I saw similar concept is at https://spacetimedb.com/ , maybe one day PostgresSQL can do the same, since it's already powerful enough to support web apps this way.
I was working in ASP.NET when projects like Backbone.js, Knockout, and Angular started to pop up. They were trying to address issues on mainstream tech at that moment (compilation times vs. hot reload, avoid full-page reloads). There was a lot of criticism around the use of JavaScript in the server back then.
Now I see the opposite. Web standards can solve the full reload page problem, so it's time to rethink if we still need to manage state in the client, with all the complexity that this involves.
The biggest issue for me it’s the division between backend and Frontend roles. I like to do both, but lately I’m doing backend. It changes a lot how we do things, refinements are mostly to create contracts between the Frontend and backend tasks, we’re they should focus on business use cases.
But I personally find SQL and triggers/stored procedures to have:
- Horrible syntax
- Poor LSP support and poor auto complete
- poor debugging experiences, error reporting, etc.
I kind of wish someone would make a better syntax with better LSP tooling and solid auto-complete. Geared compiling application logic into databases.
I would personally love to see tooling for compatibility analysis too.
It always feels weird that app logic and database are two completely different languages.
15 comments
[ 0.24 ms ] story [ 36.3 ms ] threadFor 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.
I do a lot of meta link archiving and I wanted to create a link browser. My project supports data in zipped sqlite, or JSONs.
I believe data are as much important as programs, So everything is public.
Links
https://rumca-js.github.io/search - search (JSONs)
https://rumca-js.github.io/music - music (JSONs)
https://rumca-js.github.io/bookmarks - bookmarks (JSONs)
https://github.com/rumca-js/Internet-Places-Database - scripts use SQLite
https://github.com/rumca-js/web_link_browser - clean repo of scripts
Now I see the opposite. Web standards can solve the full reload page problem, so it's time to rethink if we still need to manage state in the client, with all the complexity that this involves.
The biggest issue for me it’s the division between backend and Frontend roles. I like to do both, but lately I’m doing backend. It changes a lot how we do things, refinements are mostly to create contracts between the Frontend and backend tasks, we’re they should focus on business use cases.
I have recalled over the years this quote from his presentation: "Your app is sitting on a Ferrari-style computation engine!"
https://docs.postgrest.org/en/v13/
https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f...
It's really hard to debug and incredibly difficult to build out automated testing, controlled releases etc.
But I personally find SQL and triggers/stored procedures to have:
- Horrible syntax - Poor LSP support and poor auto complete - poor debugging experiences, error reporting, etc.
I kind of wish someone would make a better syntax with better LSP tooling and solid auto-complete. Geared compiling application logic into databases. I would personally love to see tooling for compatibility analysis too.
It always feels weird that app logic and database are two completely different languages.