Hacker News Reader

Comment by nojs | Hacker News Reader

I used to build everything with one giant “monoapp” and completely ignore that aspect of Django, which worked pretty well. Eventually though you need to split up your models into multiple files, and then your views, and admin, and so on, and it turns out there’s a lot of benefits of just segregating things into “apps” from the beginning. The only real downside I’ve noticed in practice is the omni-file-search feature in my IDE is harder to use, because you now have 7 “models.py” and it’s a bit harder to quickly navigate to the right one. If you split up files without using apps (just normal Python imports), you don't have the same problem with all the names being duplicated.

The pitch that you can "reuse" apps across projects always seemed weird to me, because that's basically never something you actually want to do/can do easily without major surgery.

View on HN

Protip on separating your models etc out: use modules instead of apps. so instead of a models.py have a models folder with a structure like this

    - models
        cheese.py
        spam.py
        __init__.py

You can then put all your cheese related models in cheese.py, and all your spam related models in spam.py. Then Simply import those models from __init__.py and django is none the wiser that anything changes. Tada: organized models without having to dive into the broken mess that is apps.

The same trick of course applies to any python file you want to split up. Views, urls, managers, etc etc.

Yeah that works pretty well too. I think there’s some minor advantages of having them in apps, they’re sorted neatly in the admin, you’re forced to split views, models, templates, admin, etc together which keeps things a bit cleaner. But it’s also messier in other ways (you have to sift through too many files to find the thing you want).

Migrations that cross app boundaries are a nightmare. Before you know it there's thousands of migrations in your various apps, and squash is powerless to help you. It'll pretend to work but break your migrations if you try to squash across any migration that depends on a migration in a different app.

IMO migrations in combinations with apps are fully broken in django. it's unworkable for large projects.

Shameless plug, I've given a talk about scaling Django codebases to many apps at PyCon (2021) and PyCon UK (2017). At my previous job we had around 500 apps in our codebase and it was honestly great to work with.

Here's the link to 2017 talk: https://www.youtube.com/watch?v=jBBcORHhfV0 Couldn't find 2021 talk that fast..

Thanks, here's the 2021 talk.

https://2021.djangocon.us/talks/scaling-django-to-500-apps/

https://www.youtube.com/watch?v=NsHo-kThlqI

I will sign onto this approach as well. Never expanded beyond a `core` app, which may have duplicated modules as the project grows (models_foo, models_bar, views_foo, views_bar, etc). I have never felt that any one component of the project was isolated enough from the rest of everything that it made sense to firewall off pieces into apps.

I’ve never successfully isolated them in the sense of having no cross imports, but I think there are advantages keeping the code broken up anyway.

Reply on news.ycombinator.com