Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some notes on starting to use Django

jvns.ca

Post reply on HN
Print view View original

131–140 of 145 posts

Re: Some notes on starting to use Django

#131

Post by Quothling »

senko wrote: post #89
graemep wrote: post #83

Earlier quoted context omitted.

> 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 e…

> 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.

While your secrets are available at runtime, you get a lot of governance by placing them in something like a keyault. You get an audit trail, you can setup rotation policies. It's easier to reference different secrets for dev, test, prod etc. I'd argue that there is a lot of added security in the fact that your developers won't actually need any sort of access to a secret stored in a keyvault, especially because you don't need to give developers access to runtime logs or even the production envrionment at all. You're right that it's not a perfect way to protect a secret of course.

Re: Some notes on starting to use Django

#132

Post by boxed »

rtpg wrote: post #125
otherme123 wrote: post #61

Earlier quoted context omitted.

> And the obvious for any Django dev; select_related, prefetch_related, annotate And sometimes not so obvious, I have been bitten by forgetting one select_related while inadvertedly joining 5 tables but using only 4 select_related: the tests work OK, but the real data has a number of records that cause a N+1. A request that used to take 100ms now issues "30 seconds timeout" from time to time. Once we added the missin…

I really want django-seal to be upstreamed, because accidental N+1's are really nasty and django-seal helps a lot with finding those

Isn't that going to be super annoying when doing interactive work or when you really can't avoid it?

Re: Some notes on starting to use Django

#133

Post by graemep »

senko wrote: post #89
graemep wrote: post #83

Earlier quoted context omitted.

> 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 e…

> Curious what extra protection this gives you, considering the environment variables are, well, in the environment, and can be read by process.

Look at it this way. What does putting things in a .env file get you over putting them in a local settings file? Both are readable by any process running as a user that can read those files, both are within the project directory and might be accidentally committed.

It also makes it easier to have a setup where secrets cannot be read by other software - e.g. this: https://www.theregister.com/2026/01/28/claude_code_ai_secret...

Re: Some notes on starting to use Django

#134

Post by agumonkey »

simonw wrote: post #107
agumonkey wrote: post #105

Earlier quoted context omitted.

Do you preemptively force yourself to allocate time for documentation maintenance ?

Not really. I have a rule that any commit which changes the implementation has to include the documentation update at the same time. Most of these documentation updates are a sentence or two, or maybe a paragraph. The overhead of incremental documentation updates like that is tiny enough that I don't really think about assigning extra time for them.

Alright, thanks a lot. Gonna help me improve my workflow :)

Re: Some notes on starting to use Django

#135

Post by perrygeo »

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.

> (configure to run in CI)

Every time I've believed this, I came back to broken CI.

Depending on your language ecosystem, your CI workflows and build deps stand a greater chance to break than your code.

Re: Some notes on starting to use Django

#136

Post by simonw »

perrygeo wrote: post #135
simonw wrote: post #17

Earlier quoted context omitted.

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.

> (configure to run in CI) Every time I've believed this, I came back to broken CI. Depending on your language ecosystem, your CI workflows and build deps stand a greater chance to break than your code.

The main thing that breaks for me is that GitHub Actions drops support for Python versions that are EOL, but usually I can fix that with a change like this one: https://github.com/simonw/datasette-scale-to-zero/commit/1ae...

Re: Some notes on starting to use Django

#138

Post by stuaxo »

selcuka wrote: post #102
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…

> Coming to a FastAPI app with alembic and finding a lot of that is build-it-yourself (and easily break it) is a bit of a shock. I briefly played with FastAPI, and after the same shock I discovered Django-Ninja [1]. It's modeled after FastAPI and async-capable (if you are inclined, but warning, there be dragons). It plays nicely with all parts of Django, including the ORM. [1] https://django-ninja.dev/

Yes, the previous time I tried to use FastAPI I moved the project to Django-Ninja and development accelerated massively.

Django has so many things that just work - I take storing the session in the database for granted and there were only half finished solutions for this.

Sorting out migrations was a pain outside of Django, even in the new project I'm in with more experienced devs on alembic a lot of things had to manually built and I regularly have to manually edit migrations.

On Django I only have to manually edit the migrations when I'm building a data migration and I can take for granted they just work.

Re: Some notes on starting to use Django

#139

Post by stuaxo »

fud101 wrote: post #117
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…

>If you ever need a CMS in your Django project I strongly recommend Wagtail, it came after the initially most popular django-cms and learned a lot of lessons - feeling much more like a part of Django. Nope. I would choose plain Django 100% of the time, especially with LLMs. Wagtail is an antipattern.

Wagtail is great for what it's good at.

If you've ever had to use Django-CMS you'd understand.

I went from a Wagtail project to a Django-CMS project (at a company that was upstreaming bits to Django-CMS) and there were so many things where it used the database badly (the usual antipattern of a loop over some queries).

It's easy to structure queries in django in an optimised way as long as you architect around .filter and not .get.

Re: Some notes on starting to use Django

#140

Post by stuaxo »

faxmeyourcode wrote: post #124
Cthulhu_ wrote: post #41

In hindsight, maybe I should've tried to use Django for my previous project instead of build a lot of custom stuff in Go and React. It was basically an admin interface, but with dozens of models and hundreds if not thousands of individual fields, each with their own validation / constraints. But it was for internal users, so visually it mainly needed to be clear.

I've lobbied to replace our internal tool with a django admin panel. I prototyped it and it showed that it would reduce our code by > 15k lines. Any internal webapps I need to build like this will 100% be set up with django in the future due to this. I don't need it to be pretty, I just want the UI, database migrations, users, roles, groups, etc for free

It's so easy to add bits to the admin as you need them.

I wish building the frontend of a Django app was as easy as the admin (though Wagtail can get close and HTMX).

Post reply on HN