Interest in async support?

[bufke]

Hello, Django's async support is decent these days. I'm curious if you would accept a pull request for async support? It would open up a lot of questions, but first I'd like to know if there is any interest at all.

The io used in allauth looks to be ORM queries and some http requests. The potential benefit, in brief, is that async would allow the server administrator to serve more with less system resources. An additional benefit may be that a new django application today could choose to use an async-first approach and anything incompatible becomes harder to work with when extending. As always - thanks for this project - I love the recent updates!

[pennersr]

Honestly, I don't see this as a priority at this stage. Unfortunately, due to the way Python async is designed (https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/) this would basically boil down to doubling all the interfaces, providing e.g. each adapter method with a sync and async variant. Now, while this certainly can be achieved, I think cleaning up interfaces first, perhaps even reaching a 1.0, before doubling the work is more important.

[Retr02332]

I was just about to create this issue. Honestly now I'm stuck, because I need an async version of this.

[bufke]

@Retr02332 if you are extending allauth in some way to work in an async context, then you need to make use of sync_to_async. If you come up with a common problem and solution, perhaps post here for others.

[jrobichaud]

I found a major problem with django-allauth and django 5's support of async views cancellation.

This might interest you all:
#3566

[pennersr]

See above mentioned -- now closed -- issues. Apparently, people are already running in async contexts. So the question is, what is currently still missing in order to close this issue?

[bbrowning918]

#3612 got us on our update to 0.60.1/current. We were on 0.54.0 with Django 4.2 running ASGI with no fuss, but not really fully leveraging async for much as other packages also face similar async adoption pains.

Just being compatible enough to run in that space, even if it's spoiling/blocking is enough of a first step, imo. "ASGI compatible but not optimized/recommended" sure seems close if we were running it that way for so long.

[bufke]

what is currently still missing in order to close this issue?

I think the use cases are:

1. I want to run allauth without error using ASGI. This seems to work fine as far as I'm aware. Any bug related to this should be tracked as it's own issue IMO and is a higher priority.
2. I want to employ python async code so as to gain the benefits of async. That is web workers which can handle more requests while using fewer system resources. This includes fetching a remote asset (such as openid connect well known), cache, or Django ORM.
3. I want to customize django allauth. I only use async functions. When I interact with django-allauth, it's harder to work with. This is the life of a Django developer at this time employing async. 🙃

If I could wave a magic wand and make allauth fully async on all io related functions, I would. It's not easy. Django ORM itself doesn't even utilize database driver async and instead wraps it in sync_to_async which causes it to execute in a thread. It's rather a pain to write async and sync versions of everything. It would be painful to instead convert all io functions to async and tell end users it's a breaking change. I would keep this issue open but consider it a long term task without any urgency.