When you have a fairly good idea of what you need to build, you can start to think about the implementation in Django. Once again, it is tempting to start coding away. However, when you spend a few minutes thinking about the design, you can find plenty of different ways to solve a design problem.
You can also start designing tests first, as advocated in Test-driven Design (TDD) methodology. We will see more of the TDD approach in the testing chapter.
Whichever approach you take, it is best to stop and think—"Which are the different ways in which I can implement this? What are the trade-offs? Which factors are more important in our context? Finally, which approach is the best?"
Experienced Django developers look at the overall project in different ways. Sticking to the DRY principle (or sometimes because they get lazy), they think—"Have I seen this functionality before? For instance, can this social login feature be implemented using a third-party package such as django-all-auth?"
If they have to write the app themselves, they start thinking of various design patterns in the hope of an elegant design. However, they first need to break down a project at the top level into apps.
Django applications are called projects. A project is made up of several applications or apps. An app is a Python package that provides a set of features.
Ideally, each app must be reusable. You can create as many apps as you need. Never be afraid to add more apps or refactor the existing ones into multiple apps. A typical Django project contains 15-20 apps.
An important decision to make at this stage is whether to use a third-party Django app or build one from scratch. Third-party apps are ready-to-use apps, which are not built by you. Most packages are quick to install and set up. You can start using them in a few minutes.
On the other hand, writing your own app often means designing and implementing the models, views, test cases, and so on yourself. Django will make no distinction between apps of either kind.
One of Django's biggest strengths is the huge ecosystem of third-party apps. At the time of writing, djangopackages.com lists more than 2,600 packages. You might find that your company or personal library has even more. Once your project is broken into apps and you know which kind of apps you need, you will need to take a call for each app—whether to write or reuse an existing one.
It might sound easier to install and use a readily available app. However, it not as simple as it sounds. Let's take a look at some third-party authentication apps for our project, and list the reasons why we didn't use them for SuperBook at the time of writing:
- Over-engineered for our needs: We felt that
python-social-authwith support for any social login was unnecessary - Too specific: Using
django-facebookwould mean tying our authentication to that provided by a specific website - Python dependencies: One of the requirements of
django-allauthispython-openid, which is not actively maintained or unapproved - Non-Python dependencies: Some packages might have non-Python dependencies, such as Redis or Node.js, which have deployment overheads
- Not reusable: Many of our own apps were not used because they were not very easy to reuse or were not written to be reusable
None of these packages are bad. They just don't meet our needs for now. They might be useful for a different project. In our case, the built-in Django auth app was good enough.
On the other hand, you might prefer to use a third-party app for some of the following reasons:
- Too hard to get right: Do your model's instances need to form a tree? Use
django-mpttfor a database-efficient implementation - Best or recommended app for the job: This changes over time but packages such as
django-redisare the most recommended for their use case - Missing batteries: Many feel that packages such as
django-model-utilsanddjango-extensionsshould have been part of the framework - Minimal dependencies: This is always good in my book
So, should you reuse apps and save time or write a new custom app? I would recommend that you try a third-party app in a sandbox. If you are an intermediate Django developer, then the next section will tell you how to try packages in a sandbox.
From time to time, you will come across several blog posts listing the "must-have Django packages". However, the best way to decide whether a package is appropriate for your project is Prototyping.
Even if you have created a Python virtual environment for development, trying all these packages and later discarding them can litter your environment. So, I usually end up creating a separate virtual environment named "sandbox" purely for trying such apps. Then, I build a small project to understand how easy it is to use.
Later, if I am happy with my test drive of the app, I create a branch in my project using a version control tool such as Git to integrate the app. Then, I continue with coding and running tests in the branch until the necessary features are added. Finally, this branch will be reviewed and merged back to the mainline (sometimes called master) branch.
To illustrate the process, our SuperBook project can be roughly broken down into the following apps (not the complete list):
- Authentication (built-in
django.auth): This app handles user signups, login, and logout - Accounts (custom): This app provides additional user profile information
- Posts (custom): This app provides posts and comments functionality
- Pows (custom): This app tracks how many "pows" (upvotes or likes) any item gets
- Bootstrap forms (crispy-forms): This app handles the form layout and styling
Here, an app has been marked to be built from scratch (tagged "custom") or the third-party Django app that we would be using. As the project progresses, these choices might change. However, this is good enough for a start.