Some more things about Django I've been enjoying • Hacker News Board

Re: Some more things about Django I've been enjoying

#51

Post by Klonoar » Sun, Jul 26, 2026, 8:24 PM UTC

0xpgm wrote: post #25

ranedk wrote: post #9

I have been using Django since 0.95 and I haven't seen anything which is so flexible with amazing DSLs while also making it easy to understand the magic behind it. For the last 10 years, even in a Golang stack or Java stack, I still use Django for models and migration. I even have generators which generate Gorm (or other framework) DAO or Java hibernate classes using Django models. With LLMs, it becomes easier since…

I've never done it, but now that you say it, it makes a lot of sense. Using Django just to manage the database and do migrations, even behind other language stacks. You also get the Django admin interface for free. I once tried using SqlAlchemy but I couldn't help asking myself why it felt so complicated compared to Django.

Running your API in Rust/Go/etc and then doing the admin and migrations via Django is a hidden superpower. I’ve said this on HN in the past few years.

Re: Some more things about Django I've been enjoying

#52

Post by loevborg » Sun, Jul 26, 2026, 8:28 PM UTC

CraigJPerry wrote: post #18

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

Please go on. I also feel like asyncio is a big hack. Even just accidentally blocking the event loop is way too easy. And I couldn't believe it when I read that you need to store a reference to a task in a set to keep it from accidentally getting canceled. How did this become the main stack of AI backends? It's like node but slower AND much easier to mess up because of synchronous IO.

Re: Some more things about Django I've been enjoying

#53

Post by lazyant » Sun, Jul 26, 2026, 8:44 PM UTC

> the site can now pretty easily handle 12 requests per second.

Right prod architecture (nginx -> gunicorn -> django, with nginx serving static assets), decent PRAGMAs for sqlite3 and caching for generic content should improve the RPS one or two orders of magnitude.

Re: Some more things about Django I've been enjoying

#54

Post by codethief » Sun, Jul 26, 2026, 8:57 PM UTC

CraigJPerry wrote: post #18

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

I would love a blog post on this, in case you ever considered writing one!

Re: Some more things about Django I've been enjoying

#55

Post by 3eb7988a1663 » Sun, Jul 26, 2026, 9:08 PM UTC

trojans1290 wrote: post #49

pdhborges wrote: post #48

Earlier quoted context omitted.

- Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries Totally agree with this. Now we have thousands of unsquashable migrations that require a ton of work to fix.

Can you share more on this? Is it better to keep all models in one app?

Not the author, but I no not understand the desire to use multiple apps. I am never going to want to carve one out as a separate module I re-use in another product. It is all interconnected, why add arbitrary boundaries separating them? Put everything into a "core" app and move on with life. Maybe if you are an enormous organization working on Instagram where you have rigid responsibilities per team.

Re: Some more things about Django I've been enjoying

#56

Post by mixmastamyk » Sun, Jul 26, 2026, 9:09 PM UTC

BrenBarn wrote: post #6

The Django filter syntax with the double underscores is like fingernails on a chalkboard to me. I find it insane that they didn't just use operator overloading to create a real query expression language.

I think you can do that with querysets, Q, and F. The kwargs are a limited convenience.

Re: Some more things about Django I've been enjoying

#57

Post by hecreto » Sun, Jul 26, 2026, 9:17 PM UTC

Not to be a downer since a lot of JEvans’ content is great. People should really give .NET a try. I don’t know if we are just old greybeard curmudgeons who look at this and go “is this a new thing? haven’t we been doing this for decades?”, but .NET out of the box with a few packages for databases, logging, etc is so pleasant you don’t even think about it. Maybe it’s just not a vocal community idk.

Re: Some more things about Django I've been enjoying

#58

Post by CraigJPerry » Sun, Jul 26, 2026, 9:19 PM UTC

loevborg wrote: post #52

CraigJPerry wrote: post #18

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

Please go on. I also feel like asyncio is a big hack. Even just accidentally blocking the event loop is way too easy. And I couldn't believe it when I read that you need to store a reference to a task in a set to keep it from accidentally getting canceled. How did this become the main stack of AI backends? It's like node but slower AND much easier to mess up because of synchronous IO.

I'm not sure i see it as a hack, but i do feel unduly burdened as a developer by async in python. I feel like there's a lot that i have to think about and i'd appreciate more help from the language.

I don't want to be overly critical, there's languages that people complain about and then there are languages that no one uses... If i compare it to js/ts, some stuff is genuinely better in Python - e.g. if you missed an await. While both ecosystems have lint tools available for this, but the behaviour is just friendlier in python.

Structured concurrency is better in python, but even if TaskGroup is nicer to use than AbortController, it still has its own foibles which means i'll usually advocate for AnyIO.

But the js/ts ecosystem just generally benefits from being async from the get-go where python you're just a time.sleep() away from a bug that will slip through dev envs and ci pipelines undetected and only rear its head under load in prod.

If i have a tip to share its the debug flag for asyncio run:

    asyncio.run(f(), debug=True)  # find some more issues before prod

Re: Some more things about Django I've been enjoying

#59

Post by trojans1290 » Sun, Jul 26, 2026, 9:22 PM UTC

3eb7988a1663 wrote: post #55

trojans1290 wrote: post #49

Earlier quoted context omitted.

Can you share more on this? Is it better to keep all models in one app?

Not the author, but I no not understand the desire to use multiple apps. I am never going to want to carve one out as a separate module I re-use in another product. It is all interconnected, why add arbitrary boundaries separating them? Put everything into a "core" app and move on with life. Maybe if you are an enormous organization working on Instagram where you have rigid responsibilities per team.

So you’d prefer one file with all models? Do you break out into apps for business logic? Keep models in one app/file. Then domain driven design elsewhere?

Re: Some more things about Django I've been enjoying

#60

Post by pdhborges » Sun, Jul 26, 2026, 9:26 PM UTC

trojans1290 wrote: post #59

3eb7988a1663 wrote: post #55

Earlier quoted context omitted.

Not the author, but I no not understand the desire to use multiple apps. I am never going to want to carve one out as a separate module I re-use in another product. It is all interconnected, why add arbitrary boundaries separating them? Put everything into a "core" app and move on with life. Maybe if you are an enormous organization working on Instagram where you have rigid responsibilities per team.

So you’d prefer one file with all models? Do you break out into apps for business logic? Keep models in one app/file. Then domain driven design elsewhere?

You don't have to put all your modules into a single file. You can break them into multiple files and the import them into a model file just so that Django loads it from the expected location.

Instead of apps you can just split your components inside a single app using regular python modules.