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

121–130 of 145 posts

Re: Some notes on starting to use Django

#121

Post by seabrookmx »

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've been really enjoying ruff/ty on my non-Django projects. Was there anything special you had to do to make ty play nice with Django? I kind of assumed with how dynamic a lot of its functionality is ty would just throw a type error for every Model.objects.whatever call.

Re: Some notes on starting to use Django

#122

Post by rtpg »

ndr wrote: post #57
jgavris wrote: post #10

The Django ORM / migrations are still basically unmatched in happiness factor.

I found it very lacking in how to do CD with no downtime. It requires a particular dance if you ever want to add/delete a field and make sure both new-code and old-code work with both new-schema and old-schema. The workaround I found was to run tests with new-schema+old-code in CI when I have schema changes, and then `makemigrations` before deploying new-code. Are there better patterns beyond "oh you can just be care…

Here's a checklist I wrote way back.

https://rtpg.co/2021/06/07/changes-checklist.html

I've been meaning to write an interactive version to sort of "prove" that you really can't do much better than this, at least in general cases.

Re: Some notes on starting to use Django

#123

Post by Humphrey »

jgavris wrote: post #10

The Django ORM / migrations are still basically unmatched in happiness factor.

100%

I am quite surprised that most languages do not have an ORM and migrations as powerful as Django. I get that it's Python's dynamic Meta programming that makes it such as clean API - but I am still surprised that there isn't much that comes close.

Re: Some notes on starting to use Django

#124

Post by faxmeyourcode »

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

Re: Some notes on starting to use Django

#125

Post by rtpg »

otherme123 wrote: post #61
sgt wrote: post #51

Earlier quoted context omitted.

You can absolutely scale Django. The framework itself is not the limiting factor. The main constraint of performance usually comes from Python itself (really slow). And possibly I/O. There are well established ways to work around that. In practice, lots of heavy lifting happens in the DB, can you can offload workloads to separate processes as well (whether those are Python, Go, Rust, Java etc). You need to identify t…

> 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

Re: Some notes on starting to use Django

#126

Post by anticodon »

el_io wrote: post #81
bodge5000 wrote: post #74

Earlier quoted context omitted.

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.

shell_plus is still superior because it also imports other useful stuff and allows adding custom list of additional imports.

Also, shell_plus has --print-sql option for easy construction and debugging of ORM queries.

Re: Some notes on starting to use Django

#127

Post by rick1290 »

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.

Agreed

Re: Some notes on starting to use Django

#128

Post by pjerem »

selcuka wrote: post #5

Django is objectively the most productive "boring technology" I've ever worked with for developing web applications. They don't regularly add too many bells and whistles on every release, but they keep it stable and reasonably backwards compatible.

I do agree.

Though i must admit that for maybe more complex applications, I feel like aspnetcore also fulfills this definition. I feel like it’s easier to create something more complex with aspnetcore while still keeping the code boring and opinionated.

I feel like Django, for bigger apps, fall apart in the "opinionated" side. For "simple" websites, you can’t go wrong, but for anything really big, basically everyone invents their own project structure.

But don’t get me wrong, I still love Django for what it is and it’s my first love in web frameworks anyway.

And I’d go further and say that the Django documentation is so awesome, that 15 years ago, it was where I learnt how websites/http/etc… really worked.

Re: Some notes on starting to use Django

#129

Post by tecoholic »

Nextgrid wrote: post #70
tecoholic wrote: post #28

Earlier quoted context omitted.

I use a project generator tool for a Django project. One of the things it does is generate setting file using string manipulation. I have been trying to think of a more sane way to do this. leverage something like dataclass or Pydantic models to have the typing information available and render a typed and validated Python object. If Django ever made that possible, it would be amazing for dev ex.

https://docs.pydantic.dev/latest/concepts/pydantic_settings/

Interesting. But it’s not straightforward with Django. So I looked up and found this

https://github.com/erhosen-libs/pydjantic

Looks promising and will play with it and see how it helps.

Re: Some notes on starting to use Django

#130

Post by Quothling »

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

If you're using UV why would you not use uv.env instead?

Post reply on HN