Earlier this year, I wrote an article that was sort of a mid-year review of popular Django projects from Github. This article follows up on that one. My criteria is slightly different, so skip to the end of the article if you want to know how I selected these projects

The Top 10

Easily add a dashboard with widgets to django-admin. Basically, use this thing for adding simple reporting needs where you want some visualizations added easily, but don’t want to spend a lot of time designing a custom display.

It uses chartist.js for building out the graphs, masonry.js for making grids, and sortable.js for dynamic ordering of tables. Compatible with Python 2 and 3; Django 1.8–1.10.

An extensible, full-featured, moderately-opinionated workflow engine. Could be useful for rolling your own ERP. Also, features a pretty nice looking GUI.

Compatible with Python 2 and 3; Django 1.9. Important note: code base hasn’t had any commits since Aug 4th, 2016, nor have there been any issues closed or PRs made since April 2016, so I hope this project is still being maintained.

Lets you keep a history of all changes to a particular model’s field. Store the field’s name, value, date and time of change, and the user that changed it.

While all this sounds close to django-reversion, please note that it isn’t a competing solution. Reversion is about tracking all the fields on a model.

Field-history lets you track specific field or set of fields instead, and it’s interested in solving only that problem. In fact, the maintainers closed an issue that would make this package compete with reversion.

Compatible with Python 2.7/3.2+; Django 1.7+.

I was on the line about including this project since its use-case seems so narrow at this point. But here it is.

graphene-django lets you implement a GraphQL API. What is GraphQL? To be overly simplistic, it’s a declarative JSON syntax that’s meant to feel like SQL: ask for data, not how to get the data, and get results back. Effectively, it’s an alternative to REST APIs that’s being pushed by Facebook.

So why is this project called graphene-django? Graphene is the python reference implementation of GraphQL.

I think this library is seeing some inflated support from people wanting to push React in the Django community, because Facebook also released relay, which is the React package to support requesting data from GraphQL endpoints.

So if your stack includes React, and you’re getting some strain from using a REST API, this project might be useful for you.

Appears to be compatible with Python 2.7/3.4–3.5; Django 1.6–1.10. (They don’t actually state that, but that’s what is passing on their builds.)

This package is a backend for caching that uses disk. Pretty obvious. But it argues that it can be as performant as in-memory caching for the fetching operation (not setting or deleting, though.) Quite the claim, but here’s the benchmark below.

Compatible with Python 2.7/3.4–3.5. Only tested on Django 1.9 currently.

If you want a REST API, but think that DRF has too much configuration, then this project was made for you. It literally adds a REST API onto django-admin endpoints with maybe 3 lines of code. So it’s extremely light.

That said, the project has no setup.py file, so you’ll literally have to clone the repo and copy the files into you project.

Additionally, there are no tests on this project yet, so compatibility is unknown. I’d expect probably Django 1.9 compatibility, but that’s a guess.

This project provides two very simple features: (1) allow a user to purge sessions from other devices, and(2) allow an admin to force a password reset on a specific user.

That’s all. Not very fancy, but extremely useful if you’re working on a project where the built-in auth features for Django are not sufficient for you.

Compatible with Python 2.7/3.4–3.5 and Django 1.8-1.9.

Another narrow feature set here: effectively, this package provides protection against accidentally making materially changes in your SQL queries.

You accomplish this by (1) writing a test using the provided context manager and (2) running that test locally, and(3) committing the resulting file to source control. Any subsequent running of that original test will compare the previously outputted file.

For example, using this project would prevent you from accidentally adding a where clause or changing a sort or adding an entirely new query, because it is not comparing queryset results, just the SQL queries itself.

Compatible with Python 2.7/3.5 and Django 1.8–1.10.

An unusual project, mypy-django is an implementation of the PEP-484 spec for the built-in Django components. Basically, if you care about static type checking, and you don’t mind using something experimental to help you, then you’ll care about this.

If you’ve never heard of this, and you’re wondering why we’re talking about static types in Python, then this is worth you reading about at least.

Compatible with Python 3.5+ and Django 1.10.

Want to gather statistics about your own models, but don’t want to rely on a third-party service? That’s what this does.

Through generic keys, If you want to do charts, reports, etc. for time series data, then this packages helps you to (1) create queries to extract that info and (2) handle the storage aspect for you.

Very important note: it will not provide you will a recurring task schedule, so don’t configure all this and wonder why your data isn’t getting recorded. You’ll need to run the queries inside of celery or something like it.

Compatibility seems a bit unclear. Python 2.7 and Django 1.9-1.10 are being tested, but it seems like they intend to test Python 3.4 as well, except their tests are misconfigured.