I keep meaning to write something like this but exploring the “how simple can you make it” angle - a lot of my world is kube (which is great in the right scenario) but could you shave complexity out of a stack designed for solo dev rapid iteration:
e.g. rather than:
> It’s important not to do any heavy data processing steps in the project-ui … we keep the browser application light while delegating the heavy lifting and business logic to the server
Chomp the complexity, serve HTML from the backend directly
> ty
Im curious where ty goes but for a min-complexity stack i couldnt spend complexity tokens on pre release tools
> pydantic … dataclasses
One or the t’other, plus i’ll forever confuse myself: is it post_init (dataclasses) or is it post_model_init (pydantic) - i had to check!
> docker
if we already have uv, could we get away without docker? uv sync can give an experience almost akin to static compiled binaries with the right setup. Its not going to handle volumes etc so if you're using docker features, this concept isnt going to fly. If you're not wedded to docker though, can you get away with just uv in dev and prod? in an enterprise prob not, i wouldn't expect to be able to download deps in prod. For flying solo though…
> compose
You’ve a frontend, a backend and presumably a database. Could you get away with just uv to manage your backend and a local sqlite db?
So a broadly feature comparable stack for rapid iteration with less complexity but still all the bells and whistles so you dont need to cook everything yourself, might look like:
You could probably sketch a path to hyper scale if you ever needed it:
- v1 = the above stack
- v2 = swap sqlite for postgres, now you unlocked multiple writers and horizontal scaling, maybe py-pglite for test envs so you can defer test-containers adoption for one more scaling iteration. WAL streaming would add some complexity to this step but worth it
- v3 = introduce containers, a container registry and test-containers. I dont think you really unlock much in this step for all that additional complexity though…
- v4 = rke2 single node cluster, no load balancer needed yet
- v5 = scale to triple node, we need a load balancer too
- v6 = add agent nodes to the rke cluster
- v7 = can you optimise costs, maybe rewrite unchanging parts in a more resource efficient stack
…
i experimented with it, i’m a fan of the concept. Ironically the bit i thought id like most (swap jinja extends shenanigans for just composing functions or callables more generally) is the bit that i didnt warm to. I dont really know why, on paper it ticks boxes for me. In practice i felt slow.
e.g. rather than:
Chomp the complexity, serve HTML from the backend directly Im curious where ty goes but for a min-complexity stack i couldnt spend complexity tokens on pre release tools One or the t’other, plus i’ll forever confuse myself: is it post_init (dataclasses) or is it post_model_init (pydantic) - i had to check! if we already have uv, could we get away without docker? uv sync can give an experience almost akin to static compiled binaries with the right setup. Its not going to handle volumes etc so if you're using docker features, this concept isnt going to fly. If you're not wedded to docker though, can you get away with just uv in dev and prod? in an enterprise prob not, i wouldn't expect to be able to download deps in prod. For flying solo though… You’ve a frontend, a backend and presumably a database. Could you get away with just uv to manage your backend and a local sqlite db?So a broadly feature comparable stack for rapid iteration with less complexity but still all the bells and whistles so you dont need to cook everything yourself, might look like:
You could probably sketch a path to hyper scale if you ever needed it: