Last year, Andrew Godwin, a Django contributor, formulated a roadmap to bring async functionality into Django. After a lot of discussion and amendments, the Django Technical Board approved his DEP 0009: Async-capable Django yesterday.
Godwin wrote in a Google group, “After a long and involved vote, I can announce that the Technical Board has voted in favour of DEP 0009 (Async Django), and so the DEP has been moved to the “accepted” state.”
The reason why Godwin thinks that this is the right time to bring async-native support in Django is that starting from version 2.1, it supports Python 3.5 and up. These Python versions have async def and similar native support for coroutines. Also, the web is now slowly shifting to use cases that prefer high concurrency workloads and large parallelizable queries.
The motivation behind Async in Django
The Django Enhancement Proposal (DEP) 0009 aims to address one of the core flaws in Python: inefficient threading. Python is not considered to be a perfect asynchronous language. Its ‘asyncio’ library for writing concurrent code suffers from some core design flaws. There are alternative async frameworks for Python but are incompatible.
Django Channels brought some async support to Django but they primarily focus on WebSocket handling. Explaining the motivation, the DEP says, “At the same time, it’s important we have a plan that delivers our users immediate benefits, rather than attempting to write a whole new Django-size framework that is natively asynchronous from the start.”
Additionally, most developers are unacquainted with developing Python applications that have async support. There is also a lack of proper documentation, tutorials, and tooling to help them. Godwin believes that Django can become a “good catalyst” to help in creating guidance documentation.
Goals this DEP outlines to achieve
The DEP proposes to bring support for asynchronous Python into Django while maintaining synchronous Python support as well in a backward-compatible way.
Here are its end goals, that Godwin listed in his roadmap:
- Making the blocking parts in Django such as sessions, auth, the ORM, and handlers asynchronous natively with a synchronous wrapper exposed on top where needed to ensure backward compatibility.
- Keeping familiar models/views/templates/middleware layout intact with very few changes.
- Ensuring that these updates do not compromise speed and cause significant performance regressions at any stage of this plan.
- Enabling developers to write fully-async websites if they want to, but not enforcing this as the default way of writing websites.
- Welcoming new talent into the Djang team to help out on large-scale features.
Timeline to achieve these goals
Godwin in his “A Django Async Roadmap” shared the following timeline:
| Django Version | Updates |
| 2.1 | Current in-progress release. No async work |
| 2.2 | Initial work to add async ORM and view capability, but everything defaults to sync by default, and async support is mostly threadpool-based. |
| 3.0 | Rewrite the internal request handling stack to be entirely asynchronous, add async middleware, forms, caching, sessions, auth. Start the deprecation process for any APIs that are becoming async-only. |
| 3.1 | Continue improving async support, potential async templating changes |
| 3.2 | Finish deprecation process and have a mostly-async Django. |
Godwin posted a summary of the discussion he had with the Django Technical Board in the Google Group. Some of the queries they raised were how the team plans to distinguish async versions of functions/method from sync ones, how this implementation will ensure that there is no performance hit if the user opts out of async mode, and more.
In addition to these technical queries, the board also raised a non-technical concern, “The Django project has lost many contributors over the years, is essentially in a maintenance mode, and we likely do not have the people to staff a project like this.” Godwin sees a massive opportunity to lurking in this fundamental challenge – namely to revive the Django project. He adds, “I agree with the observation that things have substantially slowed down, but I personally believe that a project like async is exactly what Django needs to get going again. There’s now a large amount of fertile ground to change and update things that aren’t just fixing five-year-old bugs.”
Read the DEP 0009: Async-capable Django to know more in detail.
Read Next
Which Python framework is best for building RESTful APIs? Django or Flask?
Django 2.2 is now out with classes for custom database constraints
