-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ASGI support #2666
Comments
I haven't heard of ASGI before, but if there's an "async WSGI" that's getting some traction it would make sense to add support for it. Adapting the HTTP parts of ASGI to tornado's message interfaces should be straightforward. Supporting websockets via ASGI looks more complicated because tornado's websocket module is not separated into protocol and application parts. There's also a third benefit: it would let people use tornado's HTTP server with other application frameworks. If we decoupled the server and framework parts of Tornado with ASGI, I'm not sure which side would prove more popular. :) |
So, the question might arise, is ASGI gaining traction? At the moment there are at least three independent ASGI servers (hypercorn, uvicorn, and daphne), and a few more libraries: Quart (which is basically the Flask API on ASGI), Django Channels (which is basically Django + ASGI), Starlette, Responder, and even some non-framework projects like Ariadne. Sanic too is actively working on implementing ASGI support, and while work on an official Flask implementation is a bit behind, even Flask claimed they'd support it and have interest. So we have a couple of supporters both on the server and application side. aiohttp is less enthusiastic about ASGI, they explicitly want to wait it out and avoid being one of the first adopters. Though at this point I think we are well past the point of being "first adopter", as the number of major Python web app frameworks is limited, and as you can see from the above list, many of the better known ones either have ASGI in one form or another, or are planning it. My personal view on this matter is that even if ASGI does not spread any further, if it is the least complex / most maintainable way to add a major and otherwise complex feature (like HTTP/2) and it even brings additional benefits, then to me it seems like a good choice regardless of the other projects' decision.
Sure, but that means more work for tornado, because then the server also needs to be made ASGI compatible. Though from a maintainability perspective, it would be surely better as that would mean less interface and less things to test / not break. |
Did tornado do asgi ,just like tornado.wsgi.WSGIContainer?May be tornado.asgi.ASGIContainer? |
And Django now has official ASGI support too integrated in the main product. Django 3.0 brings ASGI-support. https://www.djangoproject.com/weblog/2019/dec/02/django-3-released/ |
I write a simple handler to support asgi in tornado, if you want it, please check it out here https://github.com/plter/tornado_asgi_handler |
Do you have a plan? |
No, i just implemented what i need in my work. |
FYI: nginx now supports ASGI so it definitely seems to be gaining traction. |
What I'm wanting to do is be able to run my ASGI Django application on the same web server as Celery Flower. ASGI in tornado might be a good way to do that. |
CC, I would like to see this as well :-) |
@bdarnell Any idea after three years? |
I'm still interested in having ASGI support but have very little time for Tornado development these days. FWIW, I don't think ASGI has anything to do with the performance differences in those benchmarks. I haven't checked all of them but I believe the faster frameworks are all making more extensive use of C (or cython, etc) extensions while Tornado is pure python (except for websocket masking). |
This is a feature request / proposal to add ASGI support to tornado. Advantages are twofold:
The text was updated successfully, but these errors were encountered: