Run under an ASGI interface.

[tomchristie]

I've taken a first pass at implementing a Gunicorn worker that uses uvloop and httptools and interfaces with the application framework using an ASGI consumer interface... https://github.com/tomchristie/uvicorn (Using aiohttp and sanic as guidelines)

The intent here is to take the same set of tooling that sanic uses, but have the ASGI consumer interface as a proper layer of separation between the server and application, in the same way that we currently have for synchronous frameworks with WSGI.

I'm interested in hearing from you folks if Sanic might consider adopting the ASGI consumer interface?

• Have shared server implementations capable of interfacing with any Python framework that exposes itself as an ASGI consumer callable.
• Remove the requirement of maintaining worker and server in sanic directly.
• Add the ability to run Sanic behind a channel layer (eg. to support websocket broadcast across a cluster of servers)
• Far easier to support new protocol types (ASGI is a general purpose messaging interface)

[seemethere]

It's definitely something we have considered in the past.

I think the general consensus that we had was that we would wait until ASGI was more mature in terms of having concrete guidelines. I'd love to revisit the idea though.

[tomchristie]

Yes, I think there may still some thrashing out to do wrt. the consumer callable interface. However I'm not in any doubt that having a clear server/framework interface separation is absolutely something that we ought to be pushing towards. I'll plan to keep you folks up to date with progress on the server implementation there (which now has a name, uvicorn)

[seemethere]

Definitely digging the name @tomchristie! 😄

[tomchristie]

🦄 Had to do it, really.

[tomchristie]

I've done enough work on the uvicorn package now that the server/application interface I'm aiming for should be clear now. Any feedback most welcome.

(Other stuff still on the way: websocket support, broadcast support)

[tomchristie]

So uvicorn, and the ASGI-based messaging interface is definitely now in a state where it's a viable server for asyncio frameworks. I've been having conversations about what & why in a few different places...

• django-dev - https://groups.google.com/forum/#!topic/django-developers/_314PGl3Ao0
• aio-libs - https://groups.google.com/forum/#!topic/aio-libs/7rJ8Pb1y7aA and Initial proof-of-concept for uvicorn compatibility aio-libs/aiohttp#2035

Supporting the messaging interface it uses is a tougher sell for existing frameworks since they've already done the hard work of writing all the server code once, so the main driver behind why I think something along these lines is worth considering is because of the effect it would having on helping drive python's asyncio community forward generally.

If we can have a common interface against which to build servers and applications, as well as shared tooling, we'll be in a position to push everything forward faster. Rather than be in a position where eg. a new framework like japronto ends up having to implement an entire application and server stack, those sorts of projects could instead just target a protocol implementation.

In the middle-distance, this could make sanic faster than it already is, because it makes it far more feasible for someone to implement & maintain a server-side component in C, and only make the jump into Python application-land at the last possible hop. It also makes it possible to eg. swap out to a pure python implementation for platforms that require that, or if PyPy3 is a better target.

The shared tooling aspect is also a potential benefit. For instance I've implemented werkzeug's interactive debugger as a middleware component that any framework supporting this interface could use. I'll also be finishing off work on a WSGI adapter, that'd allow you to eg. deploy to zappa.

Anyways, mostly just something to think about for now. I'd welcome any input on the messaging interface, and I'd also certainly be up for having a first-pass look into what we'd need to do to provide this messaging interface on sanic apps, if that's something that the team are interested in.

Cheers all,

Tom

[luizberti]

I've been watching this issue and I like the progress that it's gotten so far. One of the major shortcomings of Sanic right now IMO, is the fact that unlike any other WSGI compliant project out there, it takes an immense amount of manual labor to push an HTTP API written in Sanic to something like AWS Lambda or [insert your favorite FaaS here]. This is the biggest use case I'd say Sanic is missing out on.

Even if that were not worthy of consideration, as @tomchristie said, the possibilities for improvement were this agreed upon are enormous. I'd say this is the most impactful issue open in the tracker right now.

Is there any way we can expedite this issue? What steps need to be taken to ensure compliance as of right now? If there's anything I can do to help push this issue forward please let me know, and also thank you for your contributions!

[richiverse]

Any update on this?

[luizberti]

Sadly no, it seems. @tomchristie @seemethere any thoughts on pushing this forward?

[sharkguto]

Any update?

[tomchristie]

Update from my side - ASGI's been refreshed since I filed this ticket. It was initially centered too strongly around the setup that you'd use when running Django Channels, rather than as a general purpose interface. (ie. it was server - channel layer - client interface, rather than a server - client interface.)

I worked around that at the time by having "an ASGI-based message interface" for Uvicorn, which really does present a simple server-client interface. http://www.uvicorn.org/#messaging-interface
Note the emphasis there is ASGI-based.

Since Django Channels 2.0, the ASGI spec has been revisited by @andrewgodwin, and now presents as a server-client interface.

I'm planning on updating API Star (on the client side) and Uvicorn (on the server side) to fall into line with that interface. Obviously I'd love to see Sanic eventually do the same, but not really my call there.

[CharlesSOo]

It would be nice to hear some thoughts from some of the more active members of the project.

[jordaneremieff]

Any updates from the maintainers of this project on potentially supporting ASGI? The ASGI spec now has a RTD page that can be viewed here: https://asgi.readthedocs.io/en/latest/.

[ahopkins]

Just a heads up to everyone watching this, we are actively looking into this. Checkout more discussion on the forum. This will not be in 18.12, but look for it early 2019.

[ahopkins]

I am going to close this for now. Put further discussion on the forum or #1265.