5 ms·

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 si

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?

knicholes 4y ago
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/ https://djangopackages.org/ for examples of apps people like to share.
- edmundsauto 4y ago
  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
zach_garwood 4y ago
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.
- switch007 4y ago
  100% agree. It’s a distraction
nojs 4y ago
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.
- 41b696ef1113 4y ago
  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.
  - nojs 4y ago
    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.
- Doxin 4y ago
  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.
BiteCode_dev 4y ago
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.

knicholes 4y ago

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/ https://djangopackages.org/ for examples of apps people like to share.

edmundsauto 4y ago
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

zach_garwood 4y ago

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.

switch007 4y ago
100% agree. It’s a distraction

nojs 4y ago

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.

41b696ef1113 4y ago
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.
- nojs 4y ago
  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.
Doxin 4y ago
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.

BiteCode_dev 4y ago

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.