Responses are rendered using sync_to_async

[cfra]

What is happening

adrf implements all the machinery for ViewSets and other DRF Views to be called in an async context. ✨

These views then often return a rest_framework.response.Response to be rendered by one of DRF's renderers, dependinng on the outcome of the content negotiation.

The rendering of these responses is done using a mechanism called "deferred rendering" that is implemented in Django's django.core.handlers.base.BaseHandler._get_response_async.

This mechanism checks for the presence of a render method in the Response returned by the view, and if it is present, it
will call this method to render the response.

DRF's Response object subclasses Django's django.template.response.SimpleTemplateResponse, keeping its render method, which is sync.

This causes the Django's _get_resonse_async method to call the rendering like this:

response = await sync_to_async(
    response.render, thread_sensitive=True
)()

Meaning that the rendering of responses returned by async adrf views is dispatched to another thread, and as this is happening with thread_sensitive=True being set to 1, it also means that not only are we switching to a different thread, but also we are serializing this process, so that only one request at a time can render a response.

What should happen

Ideally, adrf would implement a subclass of DRF's Response class which implements render as a coroutine, allowing the full request/response cycle of adrf to happen in an async way.

Otherwise, it would be good to at least document this behavior, so users know what kind of async concurrency they can expect while using adrf.

[avin-kavish]

So with uvicorn, is it better not to use adrf? I'm guessing asgi internal machinery handles each request without thread_sensitive=True

[cfra]

Please take the following with a grain of salt, as the matter is complicated and I am not sure that I have a full understanding of it. Also, it might be somewhat opinionated.

My understanding is that with WSGI, a single worker process can only handle one request at a time, since Django hasn't been designed to serve multiple requests using multiple threads, which I guess also wouldn't have provided much benefit given GIL.

If you run with uvicorn under ASGI, and any of your code is not async, be it middleware or views or renderers, Django will usually wrap that code with sync_to_async(..., thread_sensitive=True) to execute it in the async context of ASGI.

This wrapping often happens silently and I find that it is pretty easy to shoot yourself in the foot if you depend on async behavior for your application and you e.g. add a middleware that has no async implementation.

In this case, your application will still run fine, but requests will suddenly start blocking each other.

adrf provides async implementations for large parts of Django REST framework, allowing these parts to be executed concurrently with ASGI.

This issue documents that not all parts of the request cycle in adrf have an async implementation yet, so some code is not executed concurrently but blocking other requests. (Specifically, the renderer code)

Still, using adrf provides much better concurrency than just running Django REST framework with ASGI, which will result in all of the requests being executed in a serialized fashion.

All that being said, if you really depend on concurrent operations using async, I would suggest to also look at other frameworks than Django.

ASGI and async are not yet first class citizens in Django, for example most of the ORM's async methods just wrap the synchronous methods using sync_to_async(..., thread_sensitive=True) and there doesn't seem to be much development going on in terms of improving this situation.

Also, as I pointed out, it is pretty easy to shoot yourself in the foot with synchronous code that is lurking in the dark and will serialize your requests when you least expect it.

If you have an existing Django application and want to enable concurrency using async for some parts of it, adrf is a great tool to have in your belt.

If you start a new application that should be executed with ASGI and make full use of async based concurrency, there might be better frameworks for that purpose than Django.

[avin-kavish]

thanks for your detailed explanation.

Right, I looked the code earlier but I didn't realize it was running with thread_sensitive=True (since it's the default value)

[avin-kavish]

The thing is Django is the only real MVC framework that gives a structured approach to creating fully featured applications, DRF is a big part of it when developing REST APIs.

FastAPI doesnt have the MVC structure to it. So either you end with blob of spagghetti code in the middleware handler or you have to re-invent an MVC-like framework anyway. DRF is great fit for my purpose. I just want Django to fully finish async support.

For adrf is there a way to improve the async handling further? Happy to make a contribution if so.