| | 2 | |
| | 3 | The main problems are: |
| | 4 | |
| | 5 | 1. It strongly implies that Django's asynchronous story is unfinished. It's **often** liked to in blog posts. And it's totally misleading. The user API is essentially finished. From the PR: """Many parts of Django provide asynchronous APIs, including :ref:`the ORM <async-queries>`, the cache framework, authentication, sessions, mail, and signals. For other code, the :func:`sync_to_async` adapter is a low-cost bridge (see :ref:`async_performance`).""" |
| | 6 | |
| | 7 | 2. The performance warnings are severely outdated. `sync_to_async`/`async_to_sync` usage is in the order or microseconds with modern versions of Python. This plays directly into implementation considerations where we're constantly pulled towards duplicating whole code trees, on the mistaken assumption that `sync_to_async` usage (in particular) incurs a (relatively) massive performance hit. |
| | 8 | |
| | 9 | 3. It makes no mention of the remaining async difficulties — such as concurrent DB queries — which are **not Django specific**. In particular connection pooling is the appropriate lever to increase throughput, regardless of whether you're using Django, any other async orm, or raw connections by hand. (The current phrasing implies it's the ORM that's at fault here: it's not!) |
| | 10 | |
| | 11 | The topic doc here is a big source of the negative narrative about Django's async story. It's time to correct that. |
| | 12 | |