Add ASGI support

[pylorak]

This is a feature request / proposal to add ASGI support to tornado. Advantages are twofold:

1. It would "automatically" add HTTP/2-support to tornado given a suitable server like hypercorn or daphne. (HTTP/2 support #1438)
2. It would allow tornado users to choose their own (present or future) server to use with the tornado framework.

[bdarnell]

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. :)

[pylorak]

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.

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.

There's also a third benefit: it would let people use tornado's HTTP server with other application frameworks.

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.

[lanhao945]

Did tornado do asgi ,just like tornado.wsgi.WSGIContainer?May be tornado.asgi.ASGIContainer?

[pylorak]

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/

[plter]

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

[mcauto]

Do you have a plan?

[plter]

No, i just implemented what i need in my work.

[rhofour]

FYI: nginx now supports ASGI so it definitely seems to be gaining traction.

[ryanhiebert]

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.

[spaceone]

CC, I would like to see this as well :-)

[haobibo]

@bdarnell Any idea after three years?
Form some benckmarks, it seems that ASGI based frameworks performs better than tornado: https://github.com/klen/py-frameworks-bench