That said, I like Django. Of course, I liked Rails better, but maybe that's because it was my 'first' and I never used any of the big php frameworks for a long period of time.
I quit wasting my time with Flask for projects a while ago. It's a really great project and suited for smaller things, but you just end up re-implenting django. I'd rather someone made those decision for me.
This is an area that I think is poorly documented (both in the otherwise-great official docs and in the broader community). My advice for beginners is to just create an app called `core` and put everything there, until you have a reason to do something else. (I'd also propose putting your DJANGO_SETTINGS_MODULE aka "project name" as "django_settings" and only put your Django settings in there, but that's a little more esoteric and I'd not recommend that to a newbie in order to minimize confusion.)
In general, I think you should take the "monolith first" strategy (e.g. https://martinfowler.com/bliki/MonolithFirst.html) and just use a single app, unless you're writing something that is obviously going to be reused elsewhere.
The alternative is to attempt to define service boundaries before you know what your app's structure looks like; you'll inevitably get it wrong. And migrating models between apps is incredibly painful if you have foreign keys spanning apps.
I've also found a couple bugs in Django's migration machinery that only affect multi-app foreign key relationships; I've never seen a single-app migration bug. So there's a real cost to going down the multi-app path, which you need to balance against any benefits (I've seen none).
(Credentials/disclaimer; startup using DRF in prod for 3.5 years, mature domain model with ~50 model classes, feeling the pain of incorrectly choosing 5 apps in the initial setup instead of just using one. I'm sure there's a good argument for apps when you get to a larger scale and are sharing components/functionality between teams.)
This is spot on .... Flask is great, but it seems that to get anything substantial done with Flask you must first reimplement big chunks of Djangoesque functionality in it - why not just jump straight to Django?
in top_level_app you then could do
from second_level_app.models import model1
or from a different top level app:
from other_top_level_app.second_level_app.mixins import a_mixin
Unfortunately app names have a global namespace within Django's model registry, so we often have to prefix nested apps.
The place where this really works nicely is user facing features and internal editing interfaces, or in features where we have N of a feature that are all similar. For the former, we might have an app such as "blog", and then a nested app within that called "blog_editor". This way we can separate blog models, business logic and user-facing behaviour, from CRUD interfaces designed for internal users. In the latter, if we have 3 shipping providers, we might have an app "shipping" with the core shipping models, with nested apps for "ups", "royal_mail", "dpd", etc, each of which might have the necessary models needed to manage uploading to their APIs, business logic, etc. There may be a common-ish interface exposed by these apps.
This structure is probably the thing I like most about Django over, say, Rails. It's not necessary for all Django projects, but I think it's pretty nice.
I usually organize my apps by having a services layer between models and views, such that the view functions have little to no knowledge about the underlying models.
This, in place of nested apps, I have "upsmodels.py" and "upsservice.py" and the view functions handles routing logic.
Even if the latest version is for 1.11, the concepts are relevant.
I have been looking at a rails like framework in python called Masonite. Does anyone in the python/Django community think this will gain traction?
If you've identified some clean, generic problem where you want to reuse the code or open source it, make it a separate app. If you have a web site with areas that barely interact with each other, make it into separate apps (a chef's website where the recipes are separate from the cooking classes calendar). If you know what you're doing and feel like separate apps will help with organization, then split them up as well. Otherwise, one is fine.
For the most part there isn't any need to, with the exception of things explicitly meant to be shared. So if you are a large company and want a bunch of custom auth logic or something to be shared among many different teams running their own Django service, then you might want to build that as an app. Or else if you were building something as an open source project you might want to do the same.
In terms of separating apps by functionality, I think the main reason many people do it is because they are under the mistaken impression that putting things into different apps will make them magically re-usable. That's not to say you shouldn't do it, only that I think most people do it for the wrong reasons.
In general I would say don't bother splitting up your project into different apps by functionality until you have too many models to comfortably fit into one file. That might not be until 20KLOC. For apps that are less than 10KLOC, I think in most cases the overhead probably outweighs the benefits.
There isn't really any hard rule one how to do this, but you might do something like:
- Account management app for creating and deleting users, getting user profiles, password resets, etc.
- Apps for integrations with third-party APIs, e.g. Duns or Mailgun.
- Apps for different front doors, e.g. if you make a Facebook chat bot that's powered by the same tech that powers your normal website.
And then after that you can possibly split up your business logic of your core website into different logical components, but I would do that last. By the time you get there you should start to have a feel for how to do this.
The one place I use it for our own startup is that we recently built a couple different front doors for our site, and each one accepts data in a slightly different format and has different authentication requirements. I put each of these in their own apps, but everything else is just in one main app.
Even for larger apps in my django project, I convert my models into a package and split all my models into individual files (same with views and serializers for DRF). This keeps my models easier to manage.
- I split the core app up into different views and services based on the functionality. For FWD:Everyone this is basically: account_management, admin_apis, content_discovery, organizations, upload_thread, read_thread, comments, and user.
I have a folder for all my views and a folder for all my services, and for each view there is one (or occasionally two) service files.
So e.g. in the views folder there is a file called account_management_views, and then in the services folder there is a file called account_management_service.
For utilities that get re-used across the entire app I have two additional things in the services folder, one is called util.py and the other is io_util.py.
Util is for things like sanitizing XSS that don't require any database access, and io_util is for things like get_user_from_username, get_user_from_email_address, etc.
Then you can import any models into io_util.py, but never into util.py. And you can import anything from util.py into io_util.py, but never the other way around. Then you can import anything from either util or io_util into any service method and shouldn't have any issues. (Although I always just import util or io_util, and then call the methods like util.sanitize_xss.)
Once I structured the services and utilities that way I never had issues again with circular imports or figuring out where to put stuff. Importing with Python is kind of difficult and janky in general, but so far this pattern seems to be working pretty well for both our startup and also for the consulting projects I've done.
Basically for logic that's mostly specific to a single view, put it in the services file for that view. Public functions in that folder can still be re-used in other services, but if they're fairly generic and they're re-used in more than one or two places then consider moving them into util or io_util so as to avoid circular import issues.
- You may have stuff that may be re-used for multiple projects. For example the departments of your organization and their attributes; these should be extracted to apps so they can be easily used for other projects. Of course this would make sense if you are a software house or an organization that need multiple apps (i.e a bank) not if you are working for a single application.
- Django recommends using a custom user model. I put that in a separate app along with any related classes like user preferences etc. See also my previous bullet.
- Non related models. If you add a model that doesn't have any relation to the rest of your models then maybe you should move it to a different app? For example in one of my applications I have a NewsItem model that is just a bunch of notes that the admins can add and will be visible to the homepage; there's no need to put it in with the rest of the app (of course this also obeys the 1st bullet)
- Beyond that, usually you'll understand when you have to separate your apps. You don't need to force it, I know of huge apps with a models or views py with thousands of lines (of course in such cases even if you think that these should belong to the same app nothing's stopping you from making them a package instead of a module). However you'll usually come to a point where you think that for your reasons you need to separate
* project/models/ (each model gets it's own file here)
* project/views/ (same for views)
...and so on. And in `INSTALLED_APPS` I just add 'project'.
Makes it so I don't waste a bunch of time trying to figure out which app to put a model in, etc.
It doesn’t really swim against the current as long as you import models into the __init__.py file in their package.
The way I think about design is usually centered around the data model, so if some subject has a number of ORM models and is pretty self contained it makes sense to put them in their own app, together with related urls and views and stuff.
They still live in the same repository and aren't meant to be re-used, just split into logical parts to make the code base easier to think about. Modules, in other words.
If you don’t want “magic” then your solution is right - just use Flask.
A small nitpick: While Django may indeed fill that role, it's actually older than Rails, so wasn't "supposed" to do that. Both projects have been created independently of each other.