I think this is all well and good, especially the compatibility with Flask. However, the biggest issue is the data access layer. Most flask apps will use an ORM like SQLAlchemy(SA) to create their data access layer.
SA unfortunately, does not have a asynchronous version (its quite complex as it is). Therefore, I think it would require quite a lot of work, in order to actually get a standard flask app to work with quart.
However, if you've built your data access layer directly on psycopg, then I think you're good to go.
One thing I've never been able to reconcile is Mike Bayer's article there, set against Yury Selivanov's reported results for `asyncpg`, which at least as they're presented do indicate a significant difference in throughput.
They're both incredibly experienced developers, and I don't have any good steer on the discrepancy.
Would love to see some independent benchmarking on a typical use case to get a clearer picture on how valuable (or not) asyncio is for high-throughput database operations.
Comments
I think this is all well and good, especially the compatibility with Flask. However, the biggest issue is the data access layer. Most flask apps will use an ORM like SQLAlchemy(SA) to create their data access layer.
SA unfortunately, does not have a asynchronous version (its quite complex as it is). Therefore, I think it would require quite a lot of work, in order to actually get a standard flask app to work with quart.
However, if you've built your data access layer directly on psycopg, then I think you're good to go.
Have you any experience with GINO (https://github.com/fantix/gino) or Peewee-Async (https://github.com/05bit/peewee-async)? These look to be feasible alternatives.
Working on a Quart extension for GINO now.
An interesting deep dive on why this is the case (from 2015), in case anyone wants to know more:
http://techspot.zzzeek.org/2015/02/15/asynchronous-python-an...
One thing I've never been able to reconcile is Mike Bayer's article there, set against Yury Selivanov's reported results for `asyncpg`, which at least as they're presented do indicate a significant difference in throughput.
https://github.com/MagicStack/asyncpg
They're both incredibly experienced developers, and I don't have any good steer on the discrepancy.
Would love to see some independent benchmarking on a typical use case to get a clearer picture on how valuable (or not) asyncio is for high-throughput database operations.
Ehh...
Maybe using eventlet isn't necessarily native "async" but... it works just fine in our use cases...
http://eventlet.net/doc/modules/db_pool.html