This copied from my public gist: https://gist.github.com/abetkin/fe331872623503e24ae50d527114a554
Django 3.0: Please do not ignore the async-only usecase ============== - For how long you have considered making django async-only? - (Andrew Godwin) For about 2 minutes. @andrewgodwin yes, I decided to write this after watching your presentation at PyConAu 2019 summary -------- Please consider the usecase where a developer doesn't want to mix sync and async code, but does have a sync application and a (separate) async application and wants them to have common parts (for example, definitions of the models). the accepted approach (DEP 09) ------- The stated goal was to enable async in django, while preserving backword compatibility. The accepted approach is to make some parts of django async. Partly because it allows you to have synchronous parts in your async application (since they are easier to write), partly because django is big and its migration to async is better to be gradual (thus having a lot of sync parts at start). To provide that, it is proposed to use something like `asgiref.sync_to_async` and `asgiref.async_to_sync` adapters. The important detail is that it pins all sync handlers for a given request to a single thread. downsides ------- - sync parts exist = we still have the slowdown - the implementation is complicated. We are going from sync to async, possibly multiple times. We are required to make sync parts to be executed in the same thread, that means we cannot just use the first available thread, hence more slowdown - long-polling (one of examples that will benefit from django 3.0) is quite exotic async-only? --------- Well, it doesn't mean async-only, but it does mean that you cannot mix sync and async code. You can have gunicorn serving the sync handlers and twisted serving the async handlers, both using the same database, config, etc. Actually, you can use that aproach today. Just the amount of code you can reuse between sync and async applications is close to 0. That can be improved: the async part of django is unwritten yet, and we have some degree of freedom. orm -------- The models are mostly declarative, so conceptually there shouldn't be problems here. The same declarations of models can be used for sync and async code. Let migrations be synchronous only. Let django-admin be synchronous only. middleware ----------- Middleware will have to be implemented differently for sync and async cases. It would be nice if we could still reference same things in the configuration, like this: ``` MIDDLEWARE = [ 'common.SessionMiddleware', 'common.AuthenticationMiddleware', ] ``` Here `common.SessionMiddleware` can be an empty class, an actual implementation being provided separately for sync and async cases. DEP 09? ----- While I am personally for async-only django, that is configuration-compatible with traditional django, rather then for DEP 09, they do not exclude each other. I guess that a lot of implementation code of that DEP will be useful in async-only usecase, I am just asking to add it as a legit usecase to avoid bad API design. Actually, if there is a proper place for this writing, please tell me. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/27eaac53-3bfe-4749-86fd-ddaf6bdb8416%40googlegroups.com.
