Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
There is a get as well! All supported methods are shown in https://github.com/pallets/flask/pull/3907/files :599:
What we get with the async part of this release - If you would like to run an async library or your own async code from a flask route you can do that now. This is super useful, where let's say we have some async code that fetches data from many sources concurrently, or call multiple a few ML prediction endpoints at the same time (as long as they don't time out) using httpx and respond with some sort of outcome, or finally try that cool new async-only database library. A current (v2) limitation is that the you can't make concurrent requests using just the current asyncio implementation (an alternative with Flask API and ASGI: Quart). Typically in production gunicorn or uwsgi + threads/processes/gevent-eventlet is used and this makes Flask behave asynchronously. More here and here if interested.
flask-smorest Flask, API + OpenAPI/SwaggerUI/Redoc + Marshmallow
rebar Flask, API + OpenAPI/SwaggerUI + Marshmallow
flask-pydantic-spec Flask, API + OpenAPI/SwaggerUI/Redoc + Pydantic
flask_pydantic
What we get with the async part of this release - If you would like to run an async library or your own async code from a flask route you can do that now. This is super useful, where let's say we have some async code that fetches data from many sources concurrently, or call multiple a few ML prediction endpoints at the same time (as long as they don't time out) using httpx and respond with some sort of outcome, or finally try that cool new async-only database library. A current (v2) limitation is that the you can't make concurrent requests using just the current asyncio implementation (an alternative with Flask API and ASGI: Quart). Typically in production gunicorn or uwsgi + threads/processes/gevent-eventlet is used and this makes Flask behave asynchronously. More here and here if interested.
What we get with the async part of this release - If you would like to run an async library or your own async code from a flask route you can do that now. This is super useful, where let's say we have some async code that fetches data from many sources concurrently, or call multiple a few ML prediction endpoints at the same time (as long as they don't time out) using httpx and respond with some sort of outcome, or finally try that cool new async-only database library. A current (v2) limitation is that the you can't make concurrent requests using just the current asyncio implementation (an alternative with Flask API and ASGI: Quart). Typically in production gunicorn or uwsgi + threads/processes/gevent-eventlet is used and this makes Flask behave asynchronously. More here and here if interested.
Worth noting that I noticed a lot of online examples showing FastAPI serving Machine Learning models - (inherently cpu intensive, blocking), don't run any actual user code that's async inside the routes, so technically don't benefit from it compared to Flask. They are also often handled in sync routes def foo(): and not async routes async def foo(): which means they aren't even handled async from the get-go. In fact, internally, Starlette (and therefore by extension FastAPI) runs background tasks and non-async routes in ThreadPoolExecutor, see code here and here. It's important for those coming from DS/ML to recognize that for these use cases there's great benefit serving concurrent responses, maybe for result lookups of and db queries, but not so much with cpu-bound tasks. Being ASGI won't automatically make your app faster. And with computationally heavy tasks, just being concurrent won't make your app faster. For parallelism, (in python) multiple workers is a better strategy. Also, there's queues. More on serving computationally bound requests here