Hacker News new | ask | show | jobs
by aenis 1455 days ago
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.