Hacker News new | ask | show | jobs
by clintonc 1456 days ago
What's the advantage over using Flask's built-in support for async described here? https://flask.palletsprojects.com/en/2.1.x/async-await/

This is an honest question; I don't know much about python async yet.

4 comments

I wasn't aware of this support! That would certainly be a more natural choice if you were already familiar with Flask.

To me the biggest advantage of FastAPI is the excellent integration with type hinting. It permeates the entire framework and makes things really productive.

When I saw how you could use Pydantic models to define the schema of your request and response body, and then have that autogenerated into documentation - there was no going back. https://fastapi.tiangolo.com/tutorial/body/

But I would like to stress that, though it has displaced Flask in my workflow, I think of FastAPI as a spiritual successor to Flask, and would never say an ill word about Flask.

I looked at Flask's docs again for the first time in a few years.

And I do miss having such industrial grade documentation for my framework. I miss it real bad.

except for the autogenerated docs, you can also make use of Pydantic in Flask easily to validate your models with Flask-Pydantic[0]

[0]: https://github.com/bauerji/flask-pydantic

I’d still choose FastAPI for its dependency framework which is so much better than the god awful ‘g’.
Another advantage of FastAPI is the pydantic integration for data validation. That being said, I think FastAPI needs to find a community governance model because there are a lot of long-standing issues that the community has tried to fix only to find those fixes languishing with no official response.
What are some of the long-standing issues with FastAPI?
Fastapi and sqlmodel both suffer from this (same author).
Flask async still uses individual workers for their "async views". So, suppose your db has a bad moment and freezes for 20 seconds. All your flask worker threads become frozen on this IO - say, you have 50 of them. Your backend will time out on the 50 requests and won't even accept the 51st. Depending on how you are hosted, you may begin to autoscale aggresively because your (limited) worker threads on every node are locked. If you get lots of request you will soon find yourself running with hundreds of nodes, all of them waiting for the DB to get unstuck - and costing you money.

With a proper async framework, you will keep accepting all the requests as they come -- a single node can take thousands of those requests and time out on them gracefully, as they are just lightweight entries in the event loop, and you can have lots of those compared to # of worker threads.

Of course, fully async framework requires all your code to be fully async, which in practice means minimizing the # of dependencies since its hard to trust them. And problems with SDKs, like for instance on GCP where Google keeps lacking async support (!) for most of their things. So with the "hybrid" async you get from Flask you can still choose to use sync code for some things and async for others.

Flask still uses WSGI while other options use ASGI or other async interfaces.