Hacker News Reader

Comment by hsbauauvhabzb | Hacker News Reader

I’ve never really understood the concept of an ‘app’, in some projects I’m sure in makes sense but it not being transparent by default in a new project seems silly.

Am I missing something here?

View on HN

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.

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.

Say you want to easily create a comments app or ratings that you can associate with any other model in your project. Write that app once and use in many places. Or maybe something that sucks to write that may be error-prone, like auth, especially social auth which may change frequently. Maintaining one app and sharing it is way better than everyone trying to keep up with the changes themselves.

Or take a look at https://djangopackages.org/ for examples of apps people like to share.

Can't you just keep the logic for your comments app in the monoapp and use it with everything?

I understand if you want to distribute your app for others to incorporate, but otherwise it felt like the documentation overemphasizes the "app" aspect. It's a reasonable structure but more of a guideline... unless you want to reuse in other codebases

I think many (most?) Django apps only ever need one app. I think the fact that it's front and center in Django is a bit if a distraction that makes people think they _have_ to use multiple apps.

100% agree. It’s a distraction

The name suck, but the idea is they are plugguable: check the django packages site for an idea of the benefit of that. It's essentially a plugin system with autoloading of some resources, such as the model and templates.

Also, apps override each other in the order or import. E.g one app can override the template of another just by using the same name. This means you can plug AND extend.

Reply on news.ycombinator.com