Hi, author here. I have been building Django and DRF applications commercially for about fifteen years at DabApps, and this guidebook is an attempt to write down the architecture patterns we have arrived at, for projects that have to survive years of ongoing maintenance.
High level summary:
* We don’t hide Django under layers of abstraction, we just slice it up a bit differently than you would by default.
* Organise code by responsibility (readers, actions, interfaces, data) rather than by app.
* Put most business logic in plain functions, not in fat models or deep class hierarchies.
* Keep views thin: treat GET as "read some data" and POST as "do an action".
* Design endpoints around real frontend use cases (backend for frontend) instead of idealised resources.
* Control queries carefully to avoid performance traps.
Thank you for sharing this — I found it really fascinating and insightful. It's a shame it didn’t get more attention here. I work in an environment similar to yours and have come to similar conclusions, though not quite as "radical," for the most part.
The part about the query/values/projection of the readers layer was the most foreign to me, but I have to say, it really clicked and finally put my finger on something that’s been nagging me for a long time.
Since you mention that this came out of your work projects, I’m curious — how has your experience been onboarding developers with this way of managing Django projects?
Idiorm was started in early 2010 while I was still writing PHP professionally. I’d heard about Django from a talk @simonw gave at the FlashBrighton meet-up group in 2009 and immediately fell in love. Idiorm and Paris, although not direct attempts to duplicate Django’s ORM, came from frustration that such an elegant ORM and query builder didn’t exist in the PHP world.
So in a roundabout way, Laravel’s ORM was absolutely inspired by Django.
As a side note, I’m still doing Django 16 years later and love it more than ever.
It's worth noting that uv also supports a workflow that directly replaces pyenv, virtualenv and pip without mandating a change to a lockfile/pyproject.toml approach.
uv python pin <version> will create a .python-version file in the current directory.
uv virtualenv will download the version of Python specified in your .python-version file (like pyenv install) and create a virtualenv in the current directory called .venv using that version of Python (like pyenv exec python -m venv .venv)
uv pip install -r requirements.txt will behave the same as .venv/bin/pip install -r requirements.txt.
uv run <command> will run the command in the virtualenv and will also expose any env vars specified in a .env file (although be careful of precedence issues: https://github.com/astral-sh/uv/issues/9465)
It’s an absolute godsend. I thought poetry was a nice improvement but it had its flaws as well (constant merge conflicts in the lock file in particular).
Uv works more or less the same as I’m used to with other tooling in Ruby, JS, Rust, etc.
I never got a chance to see the difference there because I moved on shortly after.
It was just that almost constant conflicts with poetry (and the errors about the project being out of sync) with a team developing in parallel were painful enough for me to suggest we try uv instead.
It seemed uniformly better with a simpler docker setup too (although I liked how pants would created executable bundles and you could just ship those).
Fair enough! I'm a bit surprised that anyone could get regular out of sync errors unless a team member were constantly updating dependencies every commit. But then if they did that with uv I'd imagine they'd have the same issue. Unless uv does something extra smart and creates you a new environment for every git branch.
> uv will respect Python requirements defined in requires-python in the pyproject.toml file during project command invocations. The first Python version that is compatible with the requirement will be used, unless a version is otherwise requested, e.g., via a .python-version file or the --python flag.
"Lobsters is hosted on three VPSs at DigitalOcean: a s-4vcpu-8gb for the web server, a s-4vcpu-8gb for the mariadb server, and a s-1vcpu-1gb for the IRC bot. DNS is hosted at DNSimple and we use restic for backups to b2. (Setup details are available in our ansible repo.) Lobsters is cheap to run, so we don't take donations."
Do you have a source for your statement about copper? The closest I can find is [1] "The expansion of electricity networks means that copper demand for grid lines more than doubles over the same period". That's a doubling of demand, not of total current circulation.
Sorry not in circulation, my bad. The discrepance between required(for net zero) and planned mining is still worrying. Other metals like cobalt can be substituted by something else but not copper.
From the article: "It adds LLM as a dependency, and takes advantage of LLM’s Python API to abstract over the details of talking to the models. This means sqlite-utils-ask can use any of the models supported by LLM or its plugins"
from diagrams import Diagram
from diagrams.aws.compute import EC2
with Diagram("Simple Diagram"):
EC2("web")
This has a very odd API. It's using (abusing?) context managers and contextvars to do weird spooky things that you could just as easily do with ordinary objects or functions.
Depends how it's implemented. It seems very similar to Apache Airflow in API, and similar to the many Argo Workflows Python wrappers.
This pattern when implemented with context vars in the context managers is a pretty nice way to reduce the boilerplate, without the downsides of traditional globals. The state can be safely contained to just the with block.
Usually these types of APIs also allow usage without it, using the context vars only to populate arguments not explicitly provided.
it's using context managers to manage context i.e. state that is there but isn't needed to be referenced by code directly. it's the whole point. you can do it all with just functions or objects (doesn't matter, functions are objects in Python anyway) by design, context managers are there for DRY purposes.
The core implementation is only 85 lines of Python, and has no imports at all, so works nicely on minimal/alternative Pythons like Micropython.
I'm using it on a medium-sized side project and it's shockingly productive compared to string templates. I don't think anyone is using it except me, though.
This looks really neat. One suggestion is that in your readme, show the webpage output with your examples. It’s hard to image exactly what the page will look like just looking at the hotmetal python code
Nice work! There are a few expressions of this idea. There's a reason people keep coming back to it: it's actually really nice to write markup this way.
I've been looking for something exactly like this for a while — a small Python library for generating HTML that isn't prescriptive about framework and doesn't introduce any particually weird syntax. Jinja2 macros are... not great when you want to turn your HTML into lots of smaller functions.
Cool idea. I had a similar one a few weeks ago, with this additional idea of turning this into a "real" templating language (e.g. by adding a special construct for conditionals, looping, variables, macro expansion...).
This looks like a similar model to how Elm handles HTML. Except Elm provides functions for each tag, so it also does type checking to ensure that the passed arguments correspond to the actual attributes of the tag.
High level summary:
* We don’t hide Django under layers of abstraction, we just slice it up a bit differently than you would by default.
* Organise code by responsibility (readers, actions, interfaces, data) rather than by app.
* Put most business logic in plain functions, not in fat models or deep class hierarchies.
* Keep views thin: treat GET as "read some data" and POST as "do an action".
* Design endpoints around real frontend use cases (backend for frontend) instead of idealised resources.
* Control queries carefully to avoid performance traps.
Happy to answer questions!