Reuse or roll-your-own?

One of Django's biggest strengths is the huge ecosystem of third-party apps. At the time of writing, djangopackages.com lists more than 3,500 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-auth with support for any social login was unnecessary
• Too specific: Using Django-Facebook would mean tying our authentication to that provided by a specific website
• Might break other apps: Some apps can cause unintentional side effects in other apps
• Python dependencies: Some apps have dependencies that are 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:

• DRY: Do not reinvent the wheel. Take advantage of open source and well-tested apps that might be better than what you write from scratch.
• Too hard to get right: Do your model's instances need to form a tree, but also be (relational) database-efficient? Use django-mptt.
• Best or recommended app for the job: This changes over time, but packages such as django-debug-toolbar are the most recommended for their use case.

• Missing batteries: Many feel that packages such as django-model-utils and django-extensions should have been part of the framework.
• Minimal dependencies: This is always good in my book. Fewer apps means fewer unintended interactions between apps to worry about.

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.