[Django]-When to create a new app (with startapp) in Django?

James Bennett has a wonderful set of slides on how to organize reusable apps in Django.

I prefer to think of Django applications as reusable modules or components than as “applications”.

This helps me encapsulate and decouple certain features from one another, improving re-usability should I decide to share a particular “app” with the community at large, and maintainability.

My general approach is to bucket up specific features or feature sets into “apps” as though I were going to release them publicly. The hard part here is figuring out how big each bucket is.

A good trick I use is to imagine how my apps would be used if they were released publicly. This often encourages me to shrink the buckets and more clearly define its “purpose”.

Here is the updated presentation on 6 September 2008.

DjangoCon 2008: Reusable Apps @7:53

Slide: Reusable_apps.pdf

Taken from the slide

Should this be its own application?

• Is it completely unrelated to the app’s focus?
• Is it orthogonal to whatever else I’m doing?
• Will I need similar functionality on other sites?

If any of them is "Yes"? Then best to break it into a
separate application.

I tend to create new applications for each logically separate set of models. e.g.:

• User Profiles
• Forum Posts
• Blog posts

The two best answers to this question I’ve found around the web are:

1. The Reusable Apps Talk (slides)(video) also mentioned in other answers. Bennett, the author and Django contributor, regularly publishes apps for others to use and has a strong viewpoint towards many small apps.
2. Doordash’s Tips for Django at Scale which gives the opposite advice and says in their case they migrated to one single app after starting with many separate apps. They ran into problems with the migration dependency graph between apps.

Both sources agree that you should create a separate app in the following situations:

• If you plan to reuse your app in another Django project (especially if you plan to publish it for others to reuse).
• If the app has few or no dependencies between it and another app. Here you might be able to imagine an app running as its own microservice in the future.

The rule I follow is it should be a new app if I want to reuse the functionality in a different project.

If it needs deep understanding of the models in your project, it’s probably more cohesive to stick it with the models.

The best answer to this question is given by Andrew Godwin (Django core developer):

The main purpose of apps is, in my eyes, to provide logical separation of reusable components – specifically, a first-class namespace for models/admin/etc. – and to provide an easy way to turn things “on” or “off”.

In some ways, it’s a relic of the time when Django was created – when Python packaging and modules were much less developed and you basically had to have your own solution to the problem. That said, it’s still a core part of Django’s mental model, and I think INSTALLED_APPS is still a cleaner, easier solution than Python’s replacement offering of entrypoints (which makes it quite hard to disable a package that is installed in an environment but which you don’t want to use).

Is there anything specifically you think could be decoupled from the app concept today? Models and admin need it for autodiscovery and a unique namespace prefix, so that’s hard to undo, and I’m struggling to think of other features you need it for (in fact, if all you want is just a library, you can make it a normal Python one – no need for the app wrapping unless you’re shipping models, templates or admin code IIRC)

An ‘app’ could be many different things, it all really comes down to taste. For example, let’s say you are building a blog. Your app could be the entire blog, or you could have an ‘admin’ app, a ‘site’ app for all of the public views, an ‘rss’ app, a ‘services’ app so developers can interface with the blog in their own ways, etc.

I personally would make the blog itself the app, and break out the functionality within it. The blog could then be reused rather easily in other websites.

The nice thing about Django is that it will recognize any models.py file within any level of your directory tree as a file containing Django models. So breaking your functionality out into smaller ‘sub apps’ within an ‘app’ itself won’t make anything more difficult.