Discussion: Async view support

[tomchristie]

Given Django 3.1's upcoming support for async views, it's worth us talking though if there are useful points of async support in REST framework, and what they would be if so.

I'm going to prefix this by starting with a bit of expectation setting... Django 3.1's async view support is a really impressive bit of foundational work, but there's currently limitations to where it's actually valuable, given that the ORM isn't yet async-capable.

One thing that'd be really helpful to this discussion would be concrete use-cases where folks demonstrate an actual use-case where they've used or would use an async view in Django, together with the motivation, and demonstrable improvements vs. sticking with a regular sync view.

We'd also want to scoping this down to the most minimal possible starting point.

In particular, what would we need to change in order to support this?...

@api_view(['GET'])
async def my_view(request):
    ...

The @api_view decorator is implemented on top of the APIView class based view, so an even more minimal question is: what would we need to change in order to support something like this?...

class MyView(AsyncAPIView):
    async def get(self, request):
        ...

There's a whole bunch of different things to consider there, eg...

• The authentication/permissions is likely to be a sync ORM operation at the moment.
• The throttling is likely to be a sync cache operation at the moment.
• Does Django support reading the request body as an async operation? How would we need to tie this in with the parsing.

But let's just put those aside for the moment.

Django's upcoming docs for 3.1 async views mentions...

For a class-based view, this means making its __call__() method an async def
(not its __init__() or as_view()).

So here's some even simpler questions:

• What does a Django 3.1 async CBV look like?
• What would using REST framework's Request explicitly within a Django async view look like (rather than wrapping with @api_view). What provisos are there on operations on the request instance that are currently sync?
• What would using REST framework's Response explicitly within a Django async view look like (rather than wrapping with @api_view). Are there any provisos on sync operations there?

[tomchristie]

I'm dropping those comments not because they're problematic, but because I think they're derailing the issue somewhat. I don't really want to have a conversation here about the relative merits of opting for an async-native framework. There's great options there and growing support for a wider async ecosystem which encode is also playing it's part in developing.

Django is starting to gain some built-in async support. That's useful in some limited cases, and it'd be worthwhile for REST framework to track Django's async support as it grows, even if that comes with some significant caveats at this point in time.

[Kub-AT]

Btw. maybe https://github.com/hishnash/djangochannelsrestframework can be an simple inspiration

[johnthagen]

Would ❤️ some kind of native, official websocket story for DRF that allows reuse of existing DRF components.

This would help position DRF as an option for more real-time bi-directional use cases.

[pettermk]

This one is not strictly for views, but the async view would be a precondition for this to be possible. I've been wanting for some time to be able to use async in my serializers, to speed it up when I have highly IO bound calls in my custom serializer fields. Example

class CarSerializer(serializers.ModelSerializer):
    engine = serializers.SerializerMethodField()
    class Meta:
        model = Car
        fields = ('make', 'model', 'engine')

    async def get_engine(self, obj):
        return get_engine_from_manufacturer(obj.make, obj.model) # Calls slow external API for getting more data

For this simple example we would not gain a lot, but some times there are many such custom fields, or even some times I am serializing many cars in a nested serializer. In these cases I imagine there would be a lot to gain.

[manfre]

Here's a few more use cases that gain a benefit from varying degrees of async support:

• Service with a non-relational backend (e.g. DynamoDB) that avoid the ORM async complexity/issues
• Scatter gather API frontends to other services (no DB of its own)
• Post save signals for caching, cache invalidation, messaging (kafka, sqs, etc)

[shawnngtq]

Expressing my interest to see this happen!

I have seen the benchmark for fastapi and DRF, and fastapi is faster.

Would love to stick to DRF as I am comfortable with Django and don't have a lot of time to learn fastapi to quickly deliver a good performing API.

[hadim]

I am also very interested in async support in Django and DRF. Our use case is pretty common I believe. We make IO network calls within our Django models or serializers to an external API.

We try to perform most of those calls in Celery but given that those calls are not computationally intensive, that would be simpler to keep them within Django itself.

[carltongibson]

@hadim You should be able to do this already with a Django 3.1 view. Use httpx to make the network calls.

You don't even need to use ASGI. Just define an async def view and run under WSGI as normal, and Django takes care of the rest.

This seems to be the core use-case.

It's not clear what DRF needs to add? 🤔

[TheBlusky]

@carltongibson I'm not sure @api_view décorator and methods in ViewSet with @action decorator can be defined as async out of the box. That's why there might be some work in order to implement async within DRF for those views.

[carltongibson]

@TheBlusky ah, yes ViewSet... fair point.

[TheBlusky]

Is there any work on this subject ? Is there any way to help on this matter ?

[carltongibson]

@TheBlusky you could experiment with what's required to get an APIView working here. That's the first step I think.

[cochiseruhulessin]

We have a use case of downloading a file from a cloud storage provider and then passing it on to the client, async would also be a good fit for this.

A good starting point would be the APIView in implementing this feature. Basically:

• APIView __call__ must be async.
• Decorators like action must check if the decorated function is async and return appropriately.
• Async serializers?
• There is also some low-level work such as ensure that the Request object also has async methods for receiving the response body.

[gbaca]

One thing that'd be really helpful to this discussion would be concrete use-cases where folks demonstrate an actual use-case where they've used or would use an async view in Django, together with the motivation, and demonstrable improvements vs. sticking with a regular sync view.

My use case for this is a flow whereby RPC calls are made from my Django Server to RabbitMQ and all the way back to Django and the response is sent to the client who made the Django HTTP call. These RPC messages could take some time to complete and we ideally don't want our application to be blocking while waiting for the RPC reply to come into Django. We would love to use the power of DRF alongside non-blocking async capable API endpoints and all the community-packages that work on top of DRF, such as DRF Access Policy. DRF Access Policy would allow us to control access permissions while maintaining our application as async.

[patroqueeet]

@patroqueeet your use case makes me think of websockets, I don’t see how implementing async views in DRF would help 🤔

yeah, new area to me. reading all day already docu/tutorials of web socket/async views already... as I don't have web sockets in place yet but giant DRF code, I would have liked to use what we have and not grow the ecosystem of libs further...

[Skorpyon]

@patroqueeet My solution for websockets + django is next:
Django (sync backend) -> RabbitMQ (message bus) -> Aiohttp (async backend, mainly for websocket connections)

1. UI login to Aiohttp with JWT or session cookie.
2. Aiohttp kick special internal API of Django for auth, Djange response with user instance.
3. Aiohtth store pair [user_id, websocket_connection] in memory.
4. Django's threads sending messages to RabbitMq.
5. Aiohttp listen AMQP queues and obtain messages.
6. Aiohttp looking for user_id in list of open websocket channels and push messages in this channels.

Solution proven by time and good load. Actually one process of Aiohttp may handle thousands of websocket connections.

[patroqueeet]

@Skorpyon checked Aiohttp... looking very nice. but after reading ~20 articles about django/websocket/async and learning about http, starlet, unicorn, Daphne et al yesterday all day long. I will now start doing a quick prototyping based on 3.1 from this guy here https://alex-oleshkevich.medium.com/websockets-in-django-3-1-73de70c5c1ba (following the recommendation from @Crocmagnon) - I like the simplicity and I can use as much of my stack as possible. probably using DRF serializers to render and parse the JSON... Let's see how fast I can fail (making me learn even faster) :)

[danryu]

Here's my current Use Case which would really benefit from async DRF.

I have a custom user Profile which includes potentially a number of media items (image, audio) stored in S3 with django-storages.
When I upload a large file to the Profile, Django has to write the file in the POST request to the S3 backend, and thus this thread blocks for an indeterminate number of seconds while the write operation is executed.

While I can use celery etc to perform the longer-running S3 write task, it adds another layer of abstraction as I have to again serialize all the necessary values to pass to the worker queue, and create a safe way of writing the results back to the DB (probably in a sync worker).

It would be VERY convenient if I could just use async directly with the DRF API and not worry about all that extra abstraction.

[auvipy]

related django/django#14843

[Petru-design]

Any updates on this?
I have a very basic use case that could benefit a lot from async support.
I have an API server that that is connected to tens of other machines, which are somewhat old. So my setup allows the user to check up on those machines from a single dashboard, so when the user makes a query, it is forwarded to each of the machines, and they take about 10s to respond. There is no database writing or anything, I just consolidate the responses and return the result to the user, but you can see this setup is very slow just because of the dead waiting time for each of the machines.

Any advise on how to handle this situation? Feel free to request extra details if needed

[patroqueeet]

I'd assume to decouple user feedback and technology processes (status polling) would be a good approach. I used to put status tracking information simply in django cache and serve to the user from there. but that might be subject to your personal taste of "good technology" :)

[Petru-design]

I thought about this too, and implemented something like "auto update every hour" with using cached data. But I wanted to add "on demand update", where I clean the cache and redo the requests if the user specifically wanted to. But I am not sure how to best implement such a feature

[Petru-design]

So, is there any way to make this work? If not, are there any alternatives?

[Skorpyon]

If not, are there any alternatives?

FastAPI

[tomchristie]

@Petru-design There's a couple of different issues at play here, but from the way you've described the problem I think there's one that's fairly easy to address. Here's the problems...

• The length of time it's taking to send a request and receive a response is very slow. This ties up an entire thread for the duration. If your machine was under heavy load there's only a limited number of requests you'd be able to serve.
• Making multiple sequential requests is even slower. Really you'd like to be sending them in parallel.

The first point can be addressed with an async framework, or in this case async view support, because the co-operative concurrency model is far less resource intensive than the threaded concurrency model. Wherever you're waiting on a response the thread is still free to service other tasks, so you're able to continue serving a large number of responses.

The second point can be addressed by taking advantage of concurrency. Either through multiple threads, or with async using multiple tasks. You don't actually need an entire async-compatible framework (or view) in order to do this. You could use standard ol' multithreading in order to issue the requests in parallel, or else you could perfectly well spin up an async event loop specifically for the purpose of sending these requests concurrently.

It sounds to me like your problem is the second (because you've not mentioned any issues with heavy load / overloaded servers).

Personally I would deal with this by using trio (or asyncio, but honestly trio is simply a more thoroughly designed system, and does a fantastic job on the developer UX*) and httpx together within the view in order to send multiple requests.

Start out by having a look through the Trio docs, and figure out how to work that together with httpx.AsyncClient in order to send multiple requests concurrently.

Alternatively use Python's stdlib multi threading. It'd probably be absolutely fine if your server isn't under heavy load.

*: No slight on asyncio there at all, they've each been developed under different constraints, and trio has had the freedom to be able to build on top of some important insights, and finesse the design all the way though.

[lostb1t]

I/O bound tasks would benefit very much from this. You don't or can't always spin up celery (or whatever task queue system) task for these cases.

[raulzr]

Hi
My use case is the following.
We follow a microservice arquitecture. Sometimes, sevice A makes a request to service B, which makes a request to service A for some information, however service A is blocked waiting for the service B response. Of course, we have multiple workers of every service, however for some batch operations the operation could flood the service A, also with other requests of others functionalities waiting for response.

[danryu]

The most basic use-case I repeatedly come up against:

• I want to sub-class APIView in all my views to handle TokenAuthentication seamlessly across all the clients
• Each CBV typically does some mixture of ORM lookups and short-lived requests to 3rd-party APIs
• I want to benefit from the potential performance boost of Django async support

That's it :)

[rezaya92]

2022 and still no support for async?

[Tobeyforce]

I'm guessing that DRF is waiting for Django to have its async support mature a bit before adding it. It seems like a massive undertaking according to what I've heard listening to the django chat podcast. It almost strikes me as if the mindset is that for people that need native async support fastAPI is the way to go, as its been built on Tom Christie's starlette. But I'm still crossing my fingers that DRF sees support one day simply because of how popular it is with companies.

[auvipy]

as django ORM & QuerySet API & some other parts have pending async compatibility PR that is actually holding it. also maintainers interest is shifted to some were else.

[benoit9126]

Django will release some interesting updates (async orm and async views) in Django 4.1 (expected in august 2022): https://docs.djangoproject.com/en/dev/releases/4.1/#what-s-new-in-django-4-1

[johnthagen]

Django 4.1 just released with async handlers for class based views as well as an async ORM interface. 🚀

Could DRF add support?

• https://docs.djangoproject.com/en/4.1/releases/4.1/#what-s-new-in-django-4-1

import asyncio
from django.http import HttpResponse
from django.views import View

class AsyncView(View):
    async def get(self, request, *args, **kwargs):
        # Perform view logic using await.
        await asyncio.sleep(1)
        return HttpResponse("Hello async world!")

async for author in Author.objects.filter(name__startswith="A"):
    book = await author.books.afirst()

[Archmonger]

Agreed. It should now be far simpler to add async support on Django 4.1+.

[johnthagen]

Some discussion has been happening over at:

• Async Support #8496
• Async implementation #8617

[owensj-basis]

As a use case - our app has several routes that call external APIs (such as Okta's Python SDK), and we'd like to be able to run these requests asyncronously. Okta's API in particular is 100% asyncronous, so we end up having to wrap any Okta function calls in an async_to_sync in order to use them in our backend views. Being able to create async views would allow us to considerably speed up those third party API calls.

[q0w]

What about this approach hisdream86/drf-async-view (adding async implementations of existing view/request methods, not just using sync_to_async in one place (like in django and in this pr #8496) ?

[aarroisi]

Once there's support for CBVs in Django's master branch I'd be happy to take a look at this on our side.

Hi @tomchristie, now that Django 4.1 officially supports async class-based views, I hope you will be interested in including async class-based views is DRF as well in future updates.

[danryu]

I strongly believe async support in django is not first class yet.

Is there anything more concrete to back this up? In terms of open issues etc.
Otherwise it feels like this discussion is past its due date, and we can probably all unsubscribe? Three years into the discussion now and it seems like it might be time to close it out...
I'd love async DRF but it feels like the goalposts for adopting async are being continually shifted.

[Archmonger]

I also do agree that Django async support is not that great yet.

1. Nearly all third party packages are sync, causing async performance to suffer
2. All Django core middleware is sync only
3. All Django core view decorators are for sync views only
4. All Django core cache/database backends only support async in a fake way (DB connections aren't async, it's just python threading).
5. Django async performance is severely impacted by Django core prioritizing sync views (and everything mentioned above)

But I do personally believe DRF should adopt async support regardless. The more external packages that support async, the larger the pressure is on Django to prioritize it.

[tomchristie]

The Async Django REST framework package provides this support.

The next step would be a pull request adding this to the documentation.

[ionelmc]

Well I checked 4.2b1 ... sadly the authentication stuff is still sync based (the session and auth middlewares and backends) at least.

[onegreyonewhite]

Well I checked 4.2b1 ... sadly the authentication stuff is still sync based (the session and auth middlewares and backends) at least.

You need to understand how the middleware works for session and authentication in Django. They are synchronous and lazy. Therefore, I can’t imagine the profit from asynchronous drf auth backends.

If you need to implement an asynchronous authentication option, then you first need to change the middleware implementation.

P.S.: I tried to translate the project into an asynchronous manner and realized that many asynchronous parts of django are not yet fully ready and it is too early to implement in large projects.

[tomchristie]

We now have support for async views, through the Async Django REST framework package.

We're in a position to accept a pull request adding this to the documentation as a third party package.

[Archmonger]

Will this eventually be merged into the main repo, or can we expect it to continue to be a third party package?

Based on previous responses, I speculate that whether it gets considered for merge is dependent on when/if Django async becomes popular.

Right now it's half-developed in Django.

[paul-michelle]

Does not look as 'harf-developed' :) and works excellent with daphne.
If in doubt, consider how successful the starlette has grown in its fastapi re-creation

[Archmonger]

@paul-michelle While async views are supported, other parts of Django have not fully adopted async.

For example...

• Django async ORM is still undeveloped (async is currently faked via sync_to_async)
• Django async cache is still undeveloped (async is currently faked via sync_to_async)
• Built-in Django util functions do not have async variants
• Built-in Django middleware is not async
• Built-in Django serializers are not async
• Built-in Django decorators do not support async views
• Django forms do not support async
• Django user model does not support async
• Django template rendering does not support async
• Most third-party Django packages still do not use any async features
• Django's async view performance takes a significant hit due to the Django team's design decision to "prioritize sync performance at all costs"
• Django still does not have built-in ASGI lifespan support
• Django app.py:AppConfig does not support async def ready(), which means the user can't conveniently run async code during Django startup

Many, including myself (1, 2, 3, 4, 5, 6, 7, 8), have been pushing Django to embrace async via third-party packages. But unfortunately, Django itself still hasn't shown a full commitment to async (although I wish it would).

[AnhNguyen0207]

@tomchristie Is there any version that supports python 3.6 and lower django versions?

[alanjds]

@AnhNguyen0207 You can find this answer on the Installing section of the docs.

Also see https://www.django-rest-framework.org/community/3.3-announcement/#supported-versions and check which Django version you want to support.

3.3:
This release drops support for Django 1.5 and 1.6. Django 1.7, 1.8 or 1.9 are now required.

And if possible, may be better to not cite the project owner directly on a question already answered to ask about something unrelated. Opening a new question other people can help you with :)

[famdude]

adrf doesn't support lots of drf parts. actually you should implement a lot of things if you start to use adrf.
so this idea of add it to the document as a third party is not a good idea.
we still need a more stable and comprehensive solution.