Make it easier to develop async APIs

[FarhanAliRaza]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

If now I want to develop API I ll use Django rest framework, but it does not have any support for async views .

It is too frustrating to develop a simple streaming chat application.
We now have most of the components in place like StreamingHttpResponse and async views .
I know http content parsing is also being worked on.

We should have a native way to develop APIs because it is needed for many projects and many people use js frameworks for frontend.

What is missing,

Serializers like abstraction
Class based API views
CORS

Problem

Async API development

Request or proposal

request

Additional Details

No response

Implementation Suggestions

No response

[github-actions]

Thank you FarhanAliRaza for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[carltongibson]

I'd probably say this is related to/duplicate of #11.

Basically all you're missing here is a clearer story about serialisation and a set of base async generic views for handling application/json responses. I think this is a fertile space and we should allow the ecosystem to present (more) options.

adrf provides the latter currently for DRF users: https://github.com/em1208/adrf

[nanuxbe]

@FarhanAliRaza tooting my own horn here, but... Do you mean something like this but async?

Most of what we need is already there or coming.

Something cleaner than forms should probably be used for (de)serialization.

[FarhanAliRaza]

@FarhanAliRaza tooting my own horn here, but... Do you mean something like this but async?

Yes, great post btw.
I had read it before . Found on mastodon.

I wanted more formalization of API creation .Some kind of a standard builtin way.

[carltongibson]

Just on the Content Negotiation DEP, I've had my foot off the gas there, since I've personally moved almost entirely to HTML-only views. (The two year old work project has exactly 4 endpoints that return JSON, and two of those would return HTML if I redid them.)

Nonetheless there is still big demand here. I think we should advance that proposal (as it's ready etc).

[FarhanAliRaza]

Just on the Content Negotiation DEP, I've had my foot off the gas there, since I've personally moved almost entirely to HTML-only views. (The two year old work project has exactly 4 endpoints that return JSON, and two of those would return HTML if I redid them.)

Nonetheless there is still big demand here. I think we should advance that proposal (as it's ready etc).

Yes there is a lot of demand. Looking forward to it.

I mostly use a js framework as frontend and Django drf for apis.

Mostly because of.

• Tailwind and related js packages that just works (UI libraries are a big plus)

• It feels faster then full page reload. I live in Pakistan so internet situation is not so good if you are building for rural areas so building local first apps are easier

• LLMs are great at building frontend with them.

• Good of both worlds js packages + ease of Django ( personal reason. )

• Hosting cost is low . (Deploy frontend on server less solution like vercel for mostly free. + Django in some cheap vps . No need for caching, cdn on server side for small apps it just feels faster. If you do it that is cherry on top)

[nanuxbe]

Nonetheless there is still big demand here. I think we should advance that proposal (as it's ready etc).

@carltongibson let's put this on the agenda for next SC meeting?