Neat, good to see more `asyncio` frameworks coming along.<p>Python's going to have a bit of an awkward time with two completely different sets of ecosystem for threaded vs. asyncio approaches, but it's necessary progress.<p>One thing I'd be really keen to see is asyncio frameworks starting to consider adopting ASGI as a common interface. Each of quart, sanic, aiohttp currently all have their own gunicorn worker classes, http parsing, and none share the same common interface for handling the request/response interface between server and application.<p>It's a really high barrier to new asyncio frameworks, and it means we're not able to get shared middleware, such as WSGI's whitenoise or Werkzeug debugger, or the increased robustness that shared server implementations would tend to result in.<p>Would be interested to know what OP's position on this is?
Isn't this what sanic was supposed to be?<p><a href="https://github.com/channelcat/sanic" rel="nofollow">https://github.com/channelcat/sanic</a>
This looks really nice, and Flask compatibility is great.<p>One question, in the asyncio docs (really nice BTW, I hadn't tried that out yet and instantly grasped your example) you mention the common pitfall of `await awaitable.attribute` with missing brackets. In the Migration from Flask docs you give some examples where you need await like `await request.data` and `await request.get_json()` - do these need brackets in the same way or is `request` special? Same deal with `test_client` straight after that.<p>BTW, do all routes have to be async here - even your quickstart that just returns 'hello'?<p>One other thing - since you require Python 3.6 anyway it'd probably make sense to use `pipenv` instead of `venv` as your recommended install, it'd probably make your docs simpler.
The author was on a recent episode of Talk Python. <a href="https://talkpython.fm/episodes/show/147/quart-flask-but-3x-faster" rel="nofollow">https://talkpython.fm/episodes/show/147/quart-flask-but-3x-f...</a>
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.<p>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.<p>However, if you've built your data access layer directly on psycopg, then I think you're good to go.
I started dabbling with Quart a few months ago and it looks really promising. But I haven't developed any apps with it. My plan is to try building an app using it instead of Flask, I like Flask but I think this has some benefits in supporting the current future including websockets.
I've seen a few libraries like this now. Are they supposed to supersede the non asyncio versions? Is there any reason to still use flask? Will they be maintained like forks?
could you add sqlalchemy integration docs as well ? because that is where I get stuck when thinking about async. How does psycogreen work with you asyncio apis ?
Cool! Might try this for some smaller project. It's a shame that asyncio is so slow though, this framework isn't going to win any speed awards I guess.