loading...

What are the practical limitations of async Web frameworks (like Vibora)?

ankush981 profile image Ankush Thakur ・1 min read

I'm primarily a PHP developer who knows enough Python and admires the ecosystem from a distance (not that that's relevant for this discussion).

So I've been following the development of async Web frameworks in Python and am impressed that the community has responded rather quickly to the "Node threat" by producing async, highly performant frameworks. PHP has developed some solutions for this, but they are not even primitive.

Anyway, so, the question is this: what are the practical limitations of such async web frameworks?

I remember a point of discussion (though I can't remember where I came across it or in which language ecosystem) that the async framework in question doesn't give much practical benefit as almost all the popular libraries were written in a synchronous manner. I mean, Node was created with async in mind so has excellent support for it (but poor support for multi-core machines :P), which is why it excels at what it advertises.

Is this something that affects the Python's async web frameworks? What unpleasant surprises lie in wait for the unsuspecting enthusiastic developer should he choose to adopt one of these frameworks?

Posted on by:

ankush981 profile

Ankush Thakur

@ankush981

Fullstack dev working in Laravel, Node, Vue and React. Looking for bigger challenges!

Discussion

markdown guide
 

Thank you Ankush! I didn't know about Vibora, there are so many web frameworks in Python that's hard to keep track :) I checked it a little bit.

According to the GitHub the project is in alpha stage:

Warning: This project is being completely re-written. If you're curious about the progress, reach me on Slack.
Vibora is a fast, asynchronous and elegant Python 3.6+ http client/server framework. (Alpha stage)

It seems to be quite fast, it does not implement ASGI, which is the server interface that allows interoperation between servers and applications so you can easily swap the server that runs under your application without touching it, if and when there's a better option on the market. It's the equivalent of WSGI in the async world.

Anyhow, the landscape is quite active, there are so many options that people doing "comparison" articles often forget about frameworks :D

Is this something that affects the Python's async web frameworks?

Python's landscape has always had many web frameworks, people like to experiment and the whole async movement has rekindled a lot of these efforts. This is the positive aspect. The negative aspect is that I see many people essentially re-implementing the same thing.

Some frameworks are based directly on asyncio, some are based on aiohttp (which is based on asyncio), some are implemented using uvloop which is an alternative to asyncio, some like Vibora seem to support both.

There's also trio which is a completely new approach at doing async (using structured concurrency) but it's a little bit early to be considered for a production app maybe.

The main issue is that it'll take time. Python has decades of libraries that were not developed with async in mind, so you effectively need alternatives to them (because async is like a framework, once you go that route everything needs to be async), which introduce bugs and so forth and so on.

What unpleasant surprises lie in wait for the unsuspecting enthusiastic developer should he choose to adopt one of these frameworks?

If I were to choose an async framework I'd try to choose a safer choice than a library in alpha that's currently being rewritten from scratch :P

Some frameworks you might want to research: Starlette, Quart, Bocadillo (written by @florimondmanca and is built on top of starlette) and Sanic (which is not ASGI based, but they are working on it) and others
These frameworks, being ASGI based, can swap http servers like: uvicorn, daphne, hypercorn

Yes, it's all confusing :) and unfortunately for you I guess there's no "best option" easily identifiable

ps. this is a good explanation of the current state

 

Thanks for the mention, @rhymes ! Agreed with everything you said.

What unpleasant surprises lie in wait for the unsuspecting enthusiastic developer should he choose to adopt one of these frameworks?

You will most likely encounter a lack of libraries, because async is all-in. This means we kind of have to rewrite everything again (I say "kind of", because a lot of times an async wrapper of the sync library can do the job pretty well). It can be frustrating at first to have to update your library stack, but on the other hand I find getting involved and contributing to the task quite exciting.

FWIW, I wrote a small paragraph about finding async libraries in the Bocadillo docs.

 

Thanks for the response! Appreciate your spending time to contribute here! :)

 

[...] Starlette, Quart, Bocadillo [...] and Sanic [...] These frameworks, being ASGI based, can swap http servers like: uvicorn, daphne, hypercorn

Thanks for the detailed reponse! I never intended to pick on Vibora. The overall question is whether embracing an async framework will cause more headaches than convenience. I don't suppose Sanic and others are any better in this regard (since async libraries are really few)?

 

And honestly, I think the folks who just migrate to other, more relevant ecosystems (Node, Go, Elixir, Rust, whatever) instead of pulling out their hair trying to make 100 things work together and not fall apart all the time, are smarter folks! 😋😋

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

Not a really smart thing to say when there is fastapi ;)

It has done wonders for me while using it with Nuxt for production purposes. Stable and fast!