Introduction
We'll be doing a semi-regular series of blog posts about various useful Django apps. However, it seemed like a good idea to lay some groundwork first. That will help us do a few things:
- define
appalong with a few other similar terms, and get some namespace confusion out of the way - understand the value, as a developer, of creating separate apps in your Django projects
- understand the value, as a developer or end-user of a Django project, of using separate apps (third-party or internally-created) in your Django projects
What is an App? Context matters.
If you go to the Django home page, https://www.djangoproject.com, the blurb at the top says: Django makes it easier to build better web apps more quickly and with less code.
Django is often described as a web application framework or something that you use to create web applications (web apps). I've used this description myself. I have also purposefully distinguished between a web app and a website during a Django tutorial I taught. I've also written a blog post on that topic. So, if Django is used to BUILD web apps, why are we talking about apps IN Django? The context shifts a bit if you're looking at something built with Django from the outside vs. from the inside.
A View From The Inside
From the outside, the specific nomenclature is much less important. But from the inside, as someone building something with Django, the specific terminology has more meaning. But, it can still be a little confusing.
Internally, Django views an entire collection of code, what most would call a "website," as a project. This is where the settings and configuration for a specific Django website are contained. Inside that project are 1 or more apps. An app is usually a specific sub-system used within the project. It's a collection of related code that provides specific functionality that's available to the rest of the project.
A Github Example
We can look at GitHub and how its functionality is split up as an example. Note: Github is NOT built with Django. But it's a web application that's known to the people who'll probably be reading this post. So, we'll pretend Github is built in Django for this example.
Looking at the repository for Python, we can see that the issue tracker, management of pull requests, and tracking CI/CD activity are all handling different tasks in different parts of the GitHub web application. But those bits of functionality are available to be reused across the web app on each different repository. When I talk about "bits of functionality" from a Django perspective, I'm talking about the database tables, views, other code and endpoints related to each task. So, the tables, views, other code and endpoints needed to manage Github Issues would all live in one app, perhaps called issues. It would be the same for the pull_requests and ci_actions apps. As such, that functionality is available to any other part of the larger Github project. At the same time, any changes that needed to be made to one of those apps (model updates, view changes, new endpoints, etc.) can be localized in that specific app.
In Django, as with most web application frameworks, visiting a certain URL causes a specific section of code to be run. In this example, that would be the code in the issues, pull_requests or ci_actions apps.
One of the best things about apps is that they can be used between different projects. It's this reusability that makes Django apps especially valuable. In many ways, a Django app can be seen as Django's analogy to Python packages. And they serve a very similar role: you don't have to re-invent something that already exists. While most 3rd party Django apps get downloaded from PyPI like other Python packages, you can search for a Django app to fit your needs there or at Django Packages.
Building Your Own Django App
Developer-Facing Benefits
The benefits of using a third-party app are clear: you get new functionality added to your project. And you don't have to write/test/debug new code. You usually only have to make a few configuration changes.
But when it comes to the code you're writing yourself, some developers may wonder why they should bother creating separate apps inside their projects. Won't that just add extra complexity? If not, then what are the benefits?
Code Modularity
By having code that performs a specific set of functions separated into an app, it's not mixed in with your larger project monolith. As a result, you end up with code that's easier to test, document, and update. Instead of having to dig through your entire code base, you can focus on JUST the parts you need to look at. You may also improve the effectiveness of your testing by realizing that some subsystems (apps) need more or less testing than others. You can tune your coverage strategy on a per-app basis. This modularity can also provide clearer internal imports due to app namespacing.
Reusability
You may find yourself writing code that is nearly identical across multiple projects. Instead of copying/pasting that code several times and hoping you've made the right changes, you can install your app into that project. This way, any changes that need to be made to that app can be made in one place instead of several. This might not be one you've considered, given that we don't always know what the full design will be as we're working on something, and it can take time to tell if a certain chunk of code will be useful in other projects.
On the topic of reusability, this doesn't mean you have to share this app with the world. You can put it on Github and pip install it from a Git repository. That way, it's easily available to all your other projects and other developers on your team.
A Microservices Analogy
Here's another way of looking at the relationship between a Django project and an app. We can make a comparison to the monolithic and microservice approaches to software architecture. An app in Django can be compared to a microservice but with MUCH less overhead. But an app and a microservice fill similar roles. They help deal with complexity by decomposing your solution into smaller, more manageable pieces. So, if you're working on a Django project and thinking you need a microservice, that's probably a sign that you should convert part of your monolith into an app. And, if at some point you realize you truly DO need a microservice, it's much easier to convert an app into a microservice. You already have the encapsulated structure in place. In short, breaking the codebase of a monolithic Django project into apps (where appropriate, not just for the sake of doing it) can provide many of the benefits of distributed systems without most of the problems.
There may be a question about how much "overhead" there is in turning your working code into a reusable app? The answer is, "not much". I won't go into detail here, but the Django docs have you covered from start to finish.
End-User Facing Benefits
The assumption here is you are building a Django project for other people to use, not just a personal project. Perhaps it's a client you're doing freelance or agency work for. Or, you may be a developer inside a larger organization, building web apps for your co-workers to use. In situations like these, there may be concerns about "adding complexity" or "slowing down development" by creating separate apps within a larger project. As noted above, that's not really a problem, but here are a few things to keep in mind if a concern like that is raised.
There are two main benefits users of your Django project will see from creating separate apps within the project. First, all users will benefit from better naming conventions and clarity about which part of the web app they're using. Most won't care about the implementation details, but knowing that they can go directly to https://CompanyName/task_1/ or https://CompanyName/task_2/ to do what they need to will simplifiy things for them. Contrast this with needing to go to https://CompanyName/all_the_tasks/ and then search for what they need.
Second, there may be a group of staff or superusers who will have access to the Django Admin. These may be people such as managers, department heads, and the like. For those users, having your code separated into apps will create automatic separation in the Django admin. This will make it easier for those folks to find and focus on the specific app they need, instead of sorting through the entire project.
Next: Django App Of The {{ variable_time_period }}
Now that we've set a bit of foundation, we'll be looking at various Django apps and how they can be used. Some will be apps we're currently using on projects. Some will be apps we think are interesting. We probably won't be doing an app every week, but we'll try to keep the cadence regular enough to be compelling! Stay tuned!
