CODEWITHSUNDEEP
pythonpython-asynciosanic
StandardCitizen
StandardCitizen

Reputation: 81

Reasons For Python Sanic or Async Frameworks To Use Asgiref?

I understand the answer is "always depends", but generally speaking would there be a reason to use asgiref wrapper within Async frameworks such as Sanic.

https://github.com/django/asgiref https://github.com/channelcat/sanic

My main question is, why would anyone uses this within an async framework, I understand the use case for Django, but if you're async programming is thought through, something like this seems a bit of an lazy way to handle a problem.

Tell me I'm wrong.

Upvotes: 0

Views: 1140

Answers (2)

Tom Christie
Tom Christie

Reputation: 33911

First, background:

Some of the asyncio frameworks such as sanic and aiohttp predate the point at which ASGI matured, and because suitable as an asyncio server/application interface.

As a result they already have webserver implementations built into their codebases. They could switch to using ASGI as the interface, rather than their own internal interfaces, but it'd mean a bunch of work for their maintainers.

So, why might it be worth the effort?

Well, the benefit they'd get if they did do so would be:

  • Be able to run under a bunch of differing server implementations. (Either their own implementations, or any of the uvicorn, hypercorn, daphne servers.) Being able to transparently switch between server implementations gives a more robust ecosystem, and mean that server implementations can be shared across frameworks. Sanic would gain server implementation that have HTTP/2 support, Windows support, and PyPy support, and that resolve some outstanding issues it has with socket flow control.
  • Be able to benefit from shared middleware and other tooling. Being able to write middleware that works across any ASGI framework helps the ecosystem overall. You can write debugging middleware, static file serving, test clients, etc... that work with any ASGI framework, rather than having to build new things for each framework.
  • Lower complexity. Having a thoroughly designed and independent server/application interface helps reduce the surface area that developers need to consider when looking through the internals of the application framework, as it means you've got a really well documented boundary between server code and application code.
  • Composable. Because ASGI is a composable interface, you combine it in useful ways. For example, serve two different Sanic applications off the same webserver.

In short, ASGI is beneficial for the same set of reasons that WSGI was beneficial. It's less of a win for sanic than it is for anyone writing a new asyncio framework now, since they've already done all the heavy lifting of writing a server implementation, but there's still benefits they'd get from doing so, and it'd absolutely be a win for the community overall.

Related: ASGI ticket on Sanic.

(Also note asgiref is just a Python package with a few helpers for working with ASGI frameworks, that also happens to be the repo where the ASGI specification docs are kept. The question is really about using ASGI for Sanic, not using asgiref.)

Upvotes: 1

Adam Hopkins
Adam Hopkins

Reputation: 7102

I am not familiar with asgiref in particular. However, with that said, I am familiar with the idea of asgi to sort of be a replacement for wsgi.

In terms of Sanic, this is sort of irrelevant. Sanic has its own server built in, and it operates asynchronously out of the box.

I don't want to tell you that you are wrong per se, but I do not see a use for it in the Sanic world.

Upvotes: 2

Related Questions