Discussion: Async view support

[lovelydinosaur]

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?

[lovelydinosaur]

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.

[johnthagen]

@TheBlusky I think you meant to mention @carltongibson. 😄