What a neat web development stack, just html & database! No back-end and no front-end required.
(I'm not sure whether PostgREST also serves requests from inside the process, but another comment mentioned that it's a separate server process. I can see advantages to both ways.)
Where things went south for me:
- hard to hire developers that know how to work with this or that are willing to learn
- very hard to debug performance issues
- version control gets weird, since migrations are not really meant for functions and procedures (although Pyrseas[0] helped a lot)
You should almost always rewrite the system in the future, that's just the nature of growth and systems evolution.
And I'm actually not contesting the value of a regular back-end and a front-end framework: postgrest and htmx make it easy to achieve more with configuration, but this only works up to a degree. After that point the benefits of a custom application start to overweight its absence.
I _might_ introduce a load balancer to support migrating between servers with only 1-2 seconds downtime, but probably only for the duration of the move.
Edit: Oh I found it here: https://postgrest.org/en/stable/how-tos/sql-user-management....
That’s a pretty neat design. Also an interesting attack surface
“Simple” form validation is a clusterfuck and that’s what they’re leading with.
i discuss this extensively in chapter 4 of our book:
https://hypermedia.systems/extending-html-as-hypermedia/
the tldr is that htmx generalizes:
- the event that triggers an HTTP request
- the element that triggers an HTTP request
- the type of the HTTP request
- the placement of the hypermedia response to that HTTP request
In this sense, htmx adds functionality to (or, more dramatically, "completes") HTML.
This is in contrast with, for example, https://unpoly.com, which also uses HTML-over-the-wire, but provides higher level concepts (e.g. layers) and isn't as focused on generalizing hypermedia controls. This has advantages, unpoly gives you more functionality out of the box, but puts it further way from being a pure conceptual HTML extension.
My colleague James is tall and he's a basketball player. But, in one pretty straightforward sense at least, he's not a tall basketball player.
Edit: I thought of a better analogy. Compare Lodash and uBlock. Lodash is clearly a "JavaScript library", uBlock is clearly not. Why not, given that like Lodash it's just so much JavaScript? Because uBlocks' intended users don't use it as a JavaScript library. They use it to modify the default behavior of the chrome browser to something more to their liking, not as a tool for more easily expressing themselves when writing JavaScript code. I'd argue the relation of htmx to HTML is very much like that of a Chrome/VSCode extension to Chrome/VSCode: its purpose is to change the built-in behavior of some tool (HTML) used by the user, whereas a library at bottom serves an expressive purpose.