Django Async Support

[firaskafri]

We now have a solid foundation to add support for async in graphene-django (#1394), thanks to @jaw9c.

Aside from the 2x throughput mentioned by @jaw9c when running a preliminary load test #1394 (comment), not much tests have been done yet (or at-least reported) in real environments though.

I am not sure if it is a good idea to release this as an experimental feature with an advice not to use on production except for testing in on a specific async endpoint, of course just for it to be available for testing as an experimental feature, or just wait till more testing reports are available.

[firaskafri]

@jaw9c @kiendang @sjdemartini @tcleonard @ulgens @superlevure @mahdyhamad thoughts guys?

[sjdemartini]

I personally don't have an environment in which to test the async graphene-django functionality, and don't have as much familiarity with async Django to be able to review the code thoroughly, but I'd support it rolling out and calling it an experimental feature.

[kiendang]

Same here. I don't have any project that could test this out at the moment. I'm in favor of putting it out as an experimental feature but also @jaw9c's opinion is most important here since he's the sole person working on this at the moment.

[superlevure]

Unfortunately, I don't have an environment to play with it either. I'll try to set up something in the coming weeks.

Regardless, my suggestion is to conduct a benchmark on the impact of this PR on performances for both async and sync views (I've left some comments on the PR to reflect this point) before thinking about merging.

[jaw9c]

Hey guys thanks for thoughts! I'm keen to get more testing done than just running on my our platform at work - I'm going to release this to our staging env later today to run some more perf testing.

In terms of releasing as experimental, I think theres minimal risk - most of the changes only run when an async context is detected (both running under ASGI and using the async view).

What are your guys thoughts on expanding the examples in the repo to demonstrate and perf test the mode?

[david-morris]

I'm interested in this feature, but I don't know enough to know whether it'd be critical. Here's my situation:

• we run our webapp over GraphQL and have a few other endpoints for e.g. admin apps
• we often make more than graphql queries to initially load a page and would like to clean up our waterfall
• we want to add HTTP APIs outside of graphql that would generate lots of small requests; that needs to be async before we implement it.

So I have the following questions:

• can I switch Django to ASGI without taking a graphene performance hit before Support for Async Django #1394 is merged?
• can I use async to handle more requests while awaiting data from the backend in graphene resolvers before Support for Async Django #1394 is merged?
• what kinds of resources are needed to move Support for Async Django #1394 forwards?

[dima-kov]

As far as I understood, this PR is ready to be released, but repo owners don't want to merge because load tests showed significant performance drop async version vs sync.

I have some doubts regarding testing because we had two approaches for testing, and mine showed async improvement vs sync. (run without docker).

please see threads above

---

Me personally, thinking this is ready to be released, as django officially supports this way of working with "async" code during transition period when async orm will be supported from django core.

Django planning to release connection pool in August (5.1) - this was one of the biggest challenges before async orm, but still long time before orm could be considered async.
I think we are still at least one year before async django orm could be released

[dima-kov]

as for what we need to release the PR:

• the only way core maintainers agree to release - we have good load tests thats shows async/sync performance. I just have no time to finish them and find a way to properly test this