Some notes on starting to use Django • Hacker News Board

Re: Some notes on starting to use Django

#81

Post by el_io » Wed, Jan 28, 2026, 3:24 PM UTC

bodge5000 wrote: post #74

senko wrote: post #73

Some more Django recommendations from Frank Wiles of Revsys (Django consultancy): https://frankwiles.com/questions/starting-django-projects/ I'll add a few of my own: * Set up the project using uv * I name the django project "project"; so settings are project/settings.py, main urls are project/urls.py, etc * I always define a custom Django user model even if I don't need anything extra yet; easier to expand later * s…

I'll add one; Add shell_plus. It makes the django shell so much nicer to use, especially on larger projects (mostly because it auto-imports all your models). IIRC, it involves adding ipython and django_extensions as a dependency, and then adding django-extensions (annoyingly, note that the underscore changes to a dash, this trips me up everytime I add it) to your installed apps. Saying that, I'm sure django-extension…

> mostly because it auto-imports all your models

Django does this by default now. Since 5.0 if I'm remembering it correctly.

Re: Some notes on starting to use Django

#82

Post by m000 » Wed, Jan 28, 2026, 3:31 PM UTC

ndr wrote: post #72

m000 wrote: post #67

Earlier quoted context omitted.

Deploying on Kubernetes using Helm solves a lot of these cases: Migrations are run at the init stage of the pods. If successful, pods of the new version are started one by one, while the pods of the new version are shutdown. For a short period, you have pods of both versions running. When you add new stuff or make benign modifications to the schema (e.g. add an index somewhere), you won't notice a thing. If the intro…

Without care new-schema will make old-code fail user requests, that is not zero downtime.

A request not being served can happen for a multitude of reasons (many of them totally beyond your control) and the web architecture is designed around that premise.

So, if some of your pods fail a fraction of the requests they receive for a few seconds, this is not considered downtime for 99% of the use cases. The service never really stopped serving requests.

The problem is not unique to Django by any means. If you insist on being a purist, sure count it as downtime. But you will have a hard time even measuring it.

Re: Some notes on starting to use Django

#83

Post by graemep » Wed, Jan 28, 2026, 4:05 PM UTC

senko wrote: post #73

Some more Django recommendations from Frank Wiles of Revsys (Django consultancy): https://frankwiles.com/questions/starting-django-projects/ I'll add a few of my own: * Set up the project using uv * I name the django project "project"; so settings are project/settings.py, main urls are project/urls.py, etc * I always define a custom Django user model even if I don't need anything extra yet; easier to expand later * s…

> use python-dotenv to pull settings from environment / .env

I disagree strongly with this one. All you are doing is moving those settings to a different file. You might as well use a local settings file that reads the common settings.

On production keep things like API keys that need to be kept secret elsewhere - as a minimum outside the project directories and owned by a different user.

Re: Some notes on starting to use Django

#84

Post by graemep » Wed, Jan 28, 2026, 4:09 PM UTC

boxed wrote: post #36

bb88 wrote: post #7

After spending a lot of my time on Django, it's fine for simple to moderately complex things. The ORM mostly good. DRF is fine for APIs. And the admin is super nice as well. But once something gets significantly complex, the ORM starts to fall down, and DRF becomes more of a hindrance. But if you're just doing simple CRUD apps, Django is perfectly serviceable.

If you're doing simple CRUD apps, try https://iommi.rocks/ which we built because imo it's way way too slow and produces too much code to use standard Django to make CRUD stuff.

I am using it, and its a great time saver and very maintainable.

I am not using the main menu module, but tables and forms work really well.

Re: Some notes on starting to use Django

#85

Post by megaman821 » Wed, Jan 28, 2026, 4:46 PM UTC

jdahlin wrote: post #19

synack wrote: post #2

Claude Code is also very good at building basic CRUD apps with Django.

No kidding, it is really good especially with htmx which helps you get some of the advantages of a full SPA without the complexity of a separate frontend. Been building a project in the side to help my studies and it usually implement new complete apps from one prompt, working on the first try

It is probably good a HTMX for the same reason it is good at Tailwind CSS; HTMX puts the functionality on the elements being reasoned about (e.g. click this button, load the result here).

Re: Some notes on starting to use Django

#86

Post by appplication » Wed, Jan 28, 2026, 5:16 PM UTC

simonw wrote: post #17

interroboink wrote: post #6

Django aside, I think this is a really important point: Being able to abandon a project for months or years and then come back to it is really important to me (that’s how all my projects work!) ... It's perhaps especially true for a hobbyist situation, but even in a bigger environment, there is a cost to keeping people on hand who understand how XYZ works, getting new people up to speed, etc. I, too, have found found…

This is the main reason I'm extremely disciplined about making sure all of my personal projects have automated tests (configure to run in CI) and decent documentation. It makes it so much easier to pick them up again in the future when enough time has passed that I've forgotten almost everything about them.

Totally relate. My main project lately is for my wife, and it’s absolutely rock solid from a testing/automation standpoint. The last thing I want to do is accidentally break something and give her a headache when i’m just trying to build her a nice thing that brings her joy.

Re: Some notes on starting to use Django

#87

Post by appplication » Wed, Jan 28, 2026, 5:26 PM UTC

stuaxo wrote: post #78

Nice. As a mostly-django-dev for the last 15 years, who's been exposed to FastAPI and various ORMs again recently, I should get round to write a doc about some Django bits. Django is pretty nice, the changes between versions are small and can be managed by a human. Part of the reason that you can have the big ecosystem is that there is a central place to register settings and INSTALLED_APPS, middleware etc. That enab…

> As a Django dev I only just discovered the rest of the world has invented testcontainers, and databases as a solution for a problem Django solved years ago with its test database support.

Testing an API with model-bakery + pytest-django is absolutely joyous. As a TDD nerd, the lack of any remotely similar dev ex in FastAPI is the main reason I’ve never switched over.

As an aside, as someone who loves ergonomic testing, test containers are not the way. Dockerized services for testing are fine but their management is best done external to your test code. It is far easier to emulate prod by connecting to a general DB/service url that just happens to be running in a local container than have a special test harness that manages this internally to your test suite.

Re: Some notes on starting to use Django

#88

Post by 6bb32646d83d » Wed, Jan 28, 2026, 6:54 PM UTC

synack wrote: post #2

Claude Code is also very good at building basic CRUD apps with Django.

That's a huge bonus point for Django. It's so prevalent that Claude/Codex are very good at setting it up the right way, using tried and true patterns.

I've been vibe coding some side projects with Claude Code + Django + htmx/tailwind, and when it's time to go some manual work in the codebase I know exactly where things are and what they do, there's way fewer weird patterns or hack the way Claude tends to do when it's not as guided

Re: Some notes on starting to use Django

#89

Post by senko » Wed, Jan 28, 2026, 7:53 PM UTC

graemep wrote: post #83

senko wrote: post #73

Some more Django recommendations from Frank Wiles of Revsys (Django consultancy): https://frankwiles.com/questions/starting-django-projects/ I'll add a few of my own: * Set up the project using uv * I name the django project "project"; so settings are project/settings.py, main urls are project/urls.py, etc * I always define a custom Django user model even if I don't need anything extra yet; easier to expand later * s…

> use python-dotenv to pull settings from environment / .env I disagree strongly with this one. All you are doing is moving those settings to a different file. You might as well use a local settings file that reads the common settings. On production keep things like API keys that need to be kept secret elsewhere - as a minimum outside the project directories and owned by a different user.

Sure, that works as well, for example on some deploys I set the settings in systemd service file. However, it's more convenient to just have .env right there.

> On production keep things like API keys that need to be kept secret elsewhere - as a minimum outside the project directories and owned by a different user.

Curious what extra protection this gives you, considering the environment variables are, well, in the environment, and can be read by process. If someone does a remote code execution attack on the server, they can just read the environment.

The only thing I can imagine it does protect is if you mistakenly expose project root folder on the web server.

Re: Some notes on starting to use Django

#90

Post by dnautics » Wed, Jan 28, 2026, 8:34 PM UTC

3eb7988a1663 wrote: post #21

dnautics wrote: post #15

Earlier quoted context omitted.

sounds inconvenient and error-prone

It is not much code to setup the router. Now, why you would want to bounce between schemas, I do not have a good rationale, but whatever floats your boat.

yeah some frameworks call these "lenses". There's even crazy people who write lenses on top of elixir schemas because they dont realize you can just have multiple schemas.

maybe more concretely: if you have a table with a kajillion columns and you want performant views onto some column (e.g. "give me the metadata only and dont show me blobs columns") without pulling down the entire jungle in the sql request, There's that.