Why is Django not Async?

Django is not fully async, meaning it's not entirely built from the ground up for asynchronous operations like some newer frameworks. While Django has made significant strides in adopting asynchronous capabilities, certain foundational elements of its codebase remain synchronous due to underlying design choices and the nature of their state management.

The primary reason Django is not fully async is that certain key parts of the framework have global state that is not coroutine-aware. These components are classified as "async-unsafe" because they cannot operate reliably or safely within an asynchronous environment without potential issues like race conditions or data corruption. To prevent such problems, Django protects these async-unsafe parts from direct execution in an asynchronous context.

Understanding Async-Unsafe Components

The core issue stems from how some older parts of Django manage their internal state. In a synchronous, single-threaded request-response cycle, mutable global state or thread-local state is generally manageable because operations happen sequentially for a given request. However, in an asynchronous environment, multiple operations might be interleaved on a single thread (the event loop). If a global variable or shared resource is modified by one coroutine while another is reading it, inconsistencies can arise.

Global State: Some Django components historically rely on global or mutable shared state. If multiple asynchronous operations (coroutines) try to access and modify this state concurrently without proper locking or isolation mechanisms, it can lead to unpredictable behavior.
Not Coroutine-Aware: These parts were designed before Python's async/await paradigm became prevalent. They don't inherently understand the concept of cooperative multitasking or how to yield control safely, nor do they manage their internal state in a way that is thread-safe or coroutine-safe by default.

Django's Approach to Asynchrony

Despite these "async-unsafe" core parts, Django has progressively integrated async support. This includes:

Asynchronous Views: You can write async def views that handle requests asynchronously.
Asynchronous Middleware: Middleware can also be asynchronous, allowing it to work seamlessly with async views and other async components.
Asynchronous ORM: The Django ORM now offers asynchronous versions of many query methods (e.g., a_get(), a_filter(), a_save(), a_delete()) that can be awaited.
sync_to_async and async_to_sync: Django provides utilities from asgiref (the ASGI reference implementation) to bridge the gap between synchronous and asynchronous code:
- sync_to_async: This utility allows you to call synchronous code from an asynchronous context. It runs the synchronous function in a separate thread pool, preventing it from blocking the event loop. This is crucial for interacting with the aforementioned "async-unsafe" parts of Django.
- async_to_sync: Conversely, this utility allows you to call asynchronous code from a synchronous context, blocking the calling thread until the async operation completes.

Current Async Capabilities vs. Remaining Synchronous Parts

To illustrate the current state of async in Django, consider the following:

Feature/Component	Async Status (Current)	Notes
Views	`async def` supported	Can handle requests asynchronously.
Middleware	`async` middleware supported	Works with async views and applications.
ORM Query Methods	Async methods (`a_get`, etc.)	Non-blocking database operations.
Model `save()`/`delete()`	Often synchronous	Direct `save()` or `delete()` on models might still be sync-unsafe. Requires `sync_to_async` if called from async contexts.
Forms	Predominantly synchronous	Validation and processing are typically synchronous.
Templating Engine	Synchronous	Template rendering is generally a blocking operation.
Session/Auth Backends	Can be synchronous	May require `sync_to_async` for async contexts.

Practical Implications and Solutions

When building async Django applications, developers must be mindful of which parts are async-safe and which are not:

Use async def views and middleware when handling I/O-bound operations (e.g., calling external APIs, making database queries using async ORM methods).
Wrap synchronous code with sync_to_async when calling "async-unsafe" Django components from within an async def function. For example, if you need to use Django Forms or perform a synchronous ORM operation (like Model.objects.create() instead of Model.a_objects.acreate()) from an async def view, you would do:
```
from asgiref.sync import sync_to_async

async def my_async_view(request):
    # ... some async operations
    result = await sync_to_async(some_sync_function_using_forms_or_sync_orm)()
    # ...
    return HttpResponse("Hello async world!")
```
Leverage the async ORM methods: Prioritize using a_objects.acreate(), a_get(), a_filter(), etc., for database interactions within async views, as these are designed to be non-blocking.

While Django continues its journey towards greater asynchronous support, the presence of these "async-unsafe" core components means it relies on mechanisms like sync_to_async to bridge the gap, preventing it from being a fully async-first framework from its foundation.