use a hosted Postgres as a database, for fulltext search, html caching, publish/subscribe, and an event store with TimescaleDB.
A monolith that spills out HTML that is refreshed on the browser side with Hotwire Turbo with minimal Javascript. Using only managed Postgres as a database for data storage, for JSON, job handling, as a message queue, and with a columnar store as your data lake and data warehouse. If you can’t resist then add Redis for caching, because Redis never breaks.
a radical simple setup […] only uses a hosted Postgres (instead of PG, Redis and Elastic), Unpoly to render HTML on the server in a monolith and BigQuery for an analytical warehouse.
if you need REST/GraphQL for native mobile applications, use Hasura to automatically create REST/GraphQL from a Postgres database.
Fairly actionable advice, but I still think the rant tag is fitting.
So, first off I love rails & wish i could use it more.
But, we can & need to figure out how to do better.
We need a fullstack solution that can do all aspects of web solutions simply, rails & things like htmx cannot do this by their definition. - what if i wanted a rich very custom client side calendar with drag n drop & real time updates.
Now most people would say, decrease your scope, and i agree in general, but our tech should get to the point where building that is as simple as rails form building.
Our current full stack frameworks are not rails tier DX. The only thing ive seen come close is fulcro in clojure ecosystem, though i havent used it.
We are in the uncanny valley where we already have a lot of complex JavaScript frameworks, but frankly they are still too simple in scope, so the complexity of build tools & frameworks to many is not worth it.
Phoenix LiveView is a big step in the right direction, I think, although I’m only getting started with it. Hasura, which the author mentions, and related solutions (PostGraphile, PostgREST, Supabase) are also great examples of slashing tons of busy code that adds no value (such as most of what goes on inside a typical Rails/MVC application).
Hah, I’ve personally been part of one of these projects that was wildly overcomplicated and suffered for it. Not only because my full time job for two months was writing the powershell cluster build script, but also it was this weird monstrosity that used the orleans framework running on kubernetes. It was deployed on five of the fastest cloud servers you could get. Fetching a single document from the database took twelve seconds. We had ten users.
The diagnosis of us engineers craving for the next technological challenge, forgetting the real reason of our jobs (making users lives easier), is blatant.
I would add two things:
Not only we engineers love complexity, but some of us have even become cynical because they know that the more complex the system is, the more companies need so-called skilled/experienced/ninja developers who require high salary and talk more about DX than about UX. Radical simplicity seems to be a mark of humility, and I find that refreshing.
Not only radical simplicity makes it easy to get a product to market (get feedback, be Agile, get better, find success, make profit), but it’s also better from an environmental perspective: less servers, less build pipelines, less CPU used on client side… The path to tech sobriety?
I’ve tagged this a rant, as it does not have any actionable advice, nor analysis of how we got to the “here” that the author decries.
Fairly actionable advice, but I still think the rant tag is fitting.
Thanks for finding all the actionable advice. Needless to say there are perfectly good reasons not to do all of these things.
So, first off I love rails & wish i could use it more.
But, we can & need to figure out how to do better.
We need a fullstack solution that can do all aspects of web solutions simply, rails & things like htmx cannot do this by their definition. - what if i wanted a rich very custom client side calendar with drag n drop & real time updates.
Now most people would say, decrease your scope, and i agree in general, but our tech should get to the point where building that is as simple as rails form building.
Our current full stack frameworks are not rails tier DX. The only thing ive seen come close is fulcro in clojure ecosystem, though i havent used it.
We are in the uncanny valley where we already have a lot of complex JavaScript frameworks, but frankly they are still too simple in scope, so the complexity of build tools & frameworks to many is not worth it.
But we need to think bigger & more holistically.
Phoenix LiveView is a big step in the right direction, I think, although I’m only getting started with it. Hasura, which the author mentions, and related solutions (PostGraphile, PostgREST, Supabase) are also great examples of slashing tons of busy code that adds no value (such as most of what goes on inside a typical Rails/MVC application).
According to the Wayback Machine the article was published in 2021 (or perhaps earlier).
So I have suggested adding “(2021)” to the title.
Hah, I’ve personally been part of one of these projects that was wildly overcomplicated and suffered for it. Not only because my full time job for two months was writing the powershell cluster build script, but also it was this weird monstrosity that used the orleans framework running on kubernetes. It was deployed on five of the fastest cloud servers you could get. Fetching a single document from the database took twelve seconds. We had ten users.
It’s crazy that we got all this stack bloat and yet the average web app is still worse than a desktop app from 1999.
Everyone’s building constructs, nobody seems to care about the artifacts and whether they are good enough that you would want to do your job in them.
I would have loved to have written this myself.
The diagnosis of us engineers craving for the next technological challenge, forgetting the real reason of our jobs (making users lives easier), is blatant.
I would add two things: