[sammorrowdrums]

I'm surprised the discussion has derailed into whether or not to use JSON fields... Certainly you don't have to, but they've been in Postgres contrib for a long time.

Async views have dropped, and that is genuinely exciting. It's taken a lot of work, and there's still a ways to go before Django is truly async native, but this is one of the big steps, and being able to do some concurrent IO on a few routes could be a huge saving for some projects that call out.

Otherwise a lot of stuff has to be done in event queues, to avoid blocking the main thread, and sometimes that means a bad UX when users take actions and aren't offered the guarantee that they are complete - in times where that might be the best option, were you not risking blocking thread.

[btown]

As an FYI: Using a gevent monkey patch has been a way to get async Django for years. Overhead is inefficient in CPU cycles and you need to stay away from doing CPU bound things like Numpy manipulations, but for an app server that’s bound by external API call latency, it practically gives infinite concurrency compared to a thread-per-request model. And no need to worry about event queues. You can feel free to synchronously call requests.get with a 10 sec timeout and still serve prod traffic from a small handful of threads. And most days we don’t even worry about async from a coding perspective. Anyone can email me with questions.

[mgraczyk]

I'd add that crucially, DB ORM operations just work with gevent. It will be a while before async database operations are supported natively by Django. For me that is a complete blocker.

[georgewalker355]

> DB ORM operations just work with gevent

My impression was that django+gevent requires some care for the db part. The psycopg2 docs state, for instance

"Psycopg connections are not green thread safe and can’t be used concurrently by different green threads." [1,2].

In addition, gevent cannot monkey patch psycopg2 code because it is C and not python. This is handled by calling psycopg2.extensions.set_wait_callback() [1,3,4]

I just now realize that you're probably referring to making the ORM itself async capable which is on the roadmap https://code.djangoproject.com/wiki/AsyncProject in which case I totally agree.

[1] https://www.psycopg.org/docs/advanced.html#support-for-corou... [2] https://stackoverflow.com/questions/12650048/how-can-i-pool-... [3] https://github.com/gevent/gevent/blob/master/examples/psycop... [4] https://github.com/psycopg/psycogreen

[btown]

In practice this is just a one-time setup. We use https://github.com/jneight/django-db-geventpool which uses psycogreen under the hood. It isn't perfect (we're currently tracking down some rare cases where connections aren't properly returning to the pool, though we believe this to be error on our side) but it's more than sufficient.

While making the ORM async capable would be great, I'm not sure it will ever make sense to migrate towards sprinkling "async" explicitly across our codebase. We'll see, of course.

[tus88]

gevent should be in core.

[no_wizard]

Looks like they will be relying on the ASGI pattern for this? Has anyone had any practice deploying apps with ASGI?

[doteka]

Last time I tried deploying Django (with Channels) on ASGI around 2017 or 2018, it was a total clusterfuck and fell over with about 20 websocket connections, and we had to scramble to revert that deployment. That’s not ASGI’s fault though, as there are several reasonably performant frameworks using it.

[sammorrowdrums]

Have a production Django site running with Gunicorn / Uvicorn worker and we haven't hit any snags yet. Mind you we're only beginning to use it for anything in particular. The test was to check performance was acceptable, and stable - which has been our experience so far.