4 ms·

Strong opinion: DO NOT break up your project into apps. Make 1 app called core or common of whatever and replace models.py with models/<namespace_or_domain>.py

Strong opinion: DO NOT break up your project into apps. Make 1 app called core or common of whatever and replace models.py with models/<namespace_or_domain>.py and import those into models/__init__.py Everyone jumps into apps with foreign keys across app boundaries and it makes a mess of things from the start that doesnt buy you anything. 1 app. 1 set of migrations. Turn models, views, etc into a package instead of the single file module. Its the one thing I wish the docs would prescribe and demonstrate for new project advice. .

zakki 3y ago
Do you have a tutorial for more detailed example of what you wrote?
- synergy20 3y ago
  if not, please write one when you have time, short one is better than none :)
- matthiaswh 3y ago
  This tutorial addresses the practice: https://doordash.engineering/2017/05/15/tips-for-building-high-quality-django-apps-at-scale/ https://doordash.engineering/2017/05/15/tips-for-building-hi... There's also a long, uh, spirited discussion about it here with some decent arguments going both directions: https://forum.djangoproject.com/t/why-do-we-need-apps/827/19 https://forum.djangoproject.com/t/why-do-we-need-apps/827/19
pdmccormick 3y ago
After many years, I’ve come to the same conclusions and can heartily recommend these suggestions! Another similar suggestion I’d add is make a settings module with a base collection of configuration (i.e. myproject/settings/common.py) that other deployment-specific dev.py & prod.py import from. Basically, don’t forget that Django projects are always Python modules too, so go ahead and use those language features too.
appliku 3y ago
After many years of experiments i came to the same exact conclusion. In 15 years I haven't seen a single case when splitting a project into multiple apps brought anything but pain. Also, splitting files like models into packages is also a great approach. 6 months ago I found myself with models.py, API.py (my alternative for API views vs regular views) and serializes.py each over 3k lines of code. Spent 3 days splitting them into small files by topic. Way easier to work. I also wish docs suggested that it is an option and better to split them earlier. Because it is so easy to just "add one more model to the end of the file, what can go wrong?" You understand what goes wrong after 2-3k LoC
stavros 3y ago
Agreed. Only make another app if it's almost entirely decoupled from the main app, e.g. a blog app or similar.
jstarfish 3y ago
> Make 1 app called core or common Do not call it core. There's an existing app or module or something with that name and this will introduce hard-to-diagnose bugs. Common is preferable.
- jareklupinski 3y ago
  i've been getting away with calling the folder with models/views 'app' and the folder with asgi/wsgi/settings 'config' (top-folder name is the project name) so far nothing bit me other than an awkward 'app' in my installed_apps, fingers crossed
- leetrout 3y ago
  Thats a strawman. Many libs use common as well.

zakki 3y ago

Do you have a tutorial for more detailed example of what you wrote?

synergy20 3y ago
if not, please write one when you have time, short one is better than none :)
matthiaswh 3y ago
This tutorial addresses the practice: https://doordash.engineering/2017/05/15/tips-for-building-high-quality-django-apps-at-scale/ https://doordash.engineering/2017/05/15/tips-for-building-hi... There's also a long, uh, spirited discussion about it here with some decent arguments going both directions: https://forum.djangoproject.com/t/why-do-we-need-apps/827/19 https://forum.djangoproject.com/t/why-do-we-need-apps/827/19

pdmccormick 3y ago

After many years, I’ve come to the same conclusions and can heartily recommend these suggestions! Another similar suggestion I’d add is make a settings module with a base collection of configuration (i.e. myproject/settings/common.py) that other deployment-specific dev.py & prod.py import from. Basically, don’t forget that Django projects are always Python modules too, so go ahead and use those language features too.

appliku 3y ago

After many years of experiments i came to the same exact conclusion. In 15 years I haven't seen a single case when splitting a project into multiple apps brought anything but pain. Also, splitting files like models into packages is also a great approach. 6 months ago I found myself with models.py, API.py (my alternative for API views vs regular views) and serializes.py each over 3k lines of code. Spent 3 days splitting them into small files by topic. Way easier to work. I also wish docs suggested that it is an option and better to split them earlier. Because it is so easy to just "add one more model to the end of the file, what can go wrong?" You understand what goes wrong after 2-3k LoC

stavros 3y ago

Agreed. Only make another app if it's almost entirely decoupled from the main app, e.g. a blog app or similar.

jstarfish 3y ago

> Make 1 app called core or common Do not call it core. There's an existing app or module or something with that name and this will introduce hard-to-diagnose bugs. Common is preferable.

jareklupinski 3y ago
i've been getting away with calling the folder with models/views 'app' and the folder with asgi/wsgi/settings 'config' (top-folder name is the project name) so far nothing bit me other than an awkward 'app' in my installed_apps, fingers crossed
leetrout 3y ago
Thats a strawman. Many libs use common as well.