3 ms·
Exactly. If you build an async project, but do the same things than WSGI frameworks we gain nothing. We already have perfectly capable and productive frameworks
by sametmax 9y ago
Exactly. If you build an async project, but do the same things than WSGI frameworks we gain nothing. We already have perfectly capable and productive frameworks. We use them everyday, we make money with it. They work.
Async allows to maintain low latency permanent connections between each clients, being it a web page, a task queue, a server worker, etc. We finally can have it all connected. We can broadcast setting changes, propagate cache invalidation, push action notifications, update task completions to subscribers, allow everybody to react to stuff on the file system or the db instead of polling, all in soft real time.
The potential is amazing.
We all can do HTTP req / resp. The question now is: how good the tooling around this cycle is.
- aidos 9y agoYou may have already seen this but uWSGI allows you operate with asyncio too. http://uwsgi-docs.readthedocs.io/en/latest/asyncio.html http://uwsgi-docs.readthedocs.io/en/latest/asyncio.html
- sametmax 9y agoYour point ?
- aidos 9y agoSorry, it was a vague attempt to foster discussion about the options of moving out of WSGI without throwing it out completely (I was really ill yesterday and couldn't quite formulate any logic thoughts around it myself). Have you looked at the options there / if there would be an easy way to bolt on a more async driven framework? Obviously, it doesn't solve the missing framework issue, but maybe there's some clever tricks you can do because uwsgi is allowing you to bend the rules.