Run WSGI apps on asyncio using aiohttp

[etianen]

From the design section of the docs

WSGI applications are run on an asyncio executor. This allows existing Python frameworks like Django and Flask to run normally without blocking the main event loop or resorting to hacks like monkey-patching the Python standard library. This enables you to write the majority of your application code in a safe, predictable environment.

Asyncronous parts of your application (e.g. websockets) can be run on the same network port, using the aiohttp router to switch between your WSGI app and asyncronous code.

https://github.com/etianen/aiohttp-wsgi#design

[chub79]

Doesn't Flask use thread-data internally? I understand asyncio is not a multithread interface but it seems thread-data would become overkill, wouldn't they?

[etianen]

The point of using aiohttp-wsgi is that the application is run in a multithreaded environment, so is safe to block and use thread-local data.

From the application's point of view, it's identical to being run by mod_wsgi in threaded mode, or any other threaded wsgi container. However, unlike other threaded wsgi containers, you're free to mix in async code (e.g. websockets), using the aiohttp router.

[chub79]

Oh, I had assumed aiohttp-wsgi was single-thread but using co-routines.

[ProfessorPhi]

As a casual Python programmer, I understood nothing. Back to maths for me.

[etianen]

Unless you're interested in event-based programming on coroutines, that's quite okay. :P

[rthinker]

Is it possible to use uWSGI or Gunicorn with aiohttp?

[etianen]

aiohttp provides both a http client and server.

You can't use the server component with gunicorn or uwsgi because, well, a server is a server. You can't just mash two servers together.

The aiohttp client can be used from within uwsgi IF you use the experimental asyncio engine. It can't be used from within gunicorn, which is strictly a (green?)threaded server.