Considering ASGI support

@tomchristie wrote:

I’m considering taking a proper crack at ASGI support, rather than just the proof-of-concept shim of #1265.

I think you can pretty much keep API compatibility, except at some lower-level interfaces. (Eg. I would probably end up redesigning the request instantiation slightly in order to keep the implementation as clean as possible. It’d make more sense to have it be instantiated with the ASGI “scope”, rather than the existing signature.)

The event listeners are another case for consideration - ASGI just provides a “shutdown” event, rather than a “before shutdown” and “after shutdown” pair.

The easiest way to get a compatible test client would likely be something based on Starlette’s ASGI Test Client (requests dependency). That plugs a requests session directly into the ASGI interface, rather than making requests against a running instance.

You wouldn’t necessarily need to drop sanic’s built-in server, but I think it’d probably be worth doing, since uvicorn’s httptools+uvloop implementation is essentially the same stack of stuff but with an ASGI interface.

There’s a huge stack of benefits to be had here, both for Sanic, and for the ecosystem as a whole.

What’s the team’s opinion on an ASGI release that:

• Dropped the built-in server in favor of strictly decoupled-ness.
• Modified the Request.__init__ signature.
• Modified the Sanic.handle_request signature.
• before/after shutdown events with marginally different “when exactly do these run” behaviors.
• Modified test client implementation that would return request / response objects from requests rather than from aiohttp.

Are we able to break a few eggs like these in order to push things forward, or would a PR along those lines be a non-starter?

Read full topic