Curious choice of backend python. Indeed Flask is a famous python framework but it seems it has been completely overshadowed by FastAPI.
I would suggest "HyperFastAPI"
A lot of people moved from Flask to FastAPI because the latter is built for async workloads by default. So, people expected massive performance improvements because the word async was associated with performance.
In reality, people ended up having to deal with weird bugs because asynchronous Python isn't the most ergonomic, while having negligible to zero performance improvements. Proof that most people are terrible at choosing tech stacks.
Then, AI came into the scene and people were building APIs that were essentilly front-ends to third party LLM APIs. For example, people could build an API that will contact OpenAI before returning a response. That's where FastAPI truly shined because of native asynchronous views which provides better performance over Flask's async implementation. Then people realized that can can simply access OpenAI's API instead of calling another front-end API first. But now they're already invested in FastAPI, so changing to another framework isn't going to happen.
Either way, I like FastAPI and I think Sebatian Ramirez is a great dude who knows what he wants. I have respect for a person who know how to say no. But it's unfortunate that people believe that Flask is irrelevant just because FastAPI exists.
> In reality, people ended up having to deal with weird bugs because asynchronous Python isn't the most ergonomic
That is an understatement. I loathe working with async Python.
> For example, people could build an API that will contact OpenAI before returning a response. That's where FastAPI truly shined because of native asynchronous views which provides better performance over Flask's async implementation.
TO be fair there are lots of other things that require a response from an API before responding to the request and therefore async reduces resource usage over threads or multi-process.
> TO be fair there are lots of other things that require a response from an API before responding to the request and therefore async reduces resource usage over threads or multi-process.
Agreed. However, these are rare and many people have been abusing asynchronous views instead of delegating the task to a background worker when multiple external requests are required. Showing a spinner while polling a synchronous view is dead simple to implement and more resilient against unexpected outages.
I agree with this. For real life stuff, Flask (or Django for that matter, my preference) is preferable over FastAPI. I used FastAPI recently for something that needed super fast (relatively speaking) async. And you just need to build a lot of stuff yourself which wastes time, comparatively speaking. If I had known, I'd probably have done it in Django and rather used Daphne or something.
Interesting. But is it also not just that Flask was build more for making websites in general, and FastAPI for making REST APIs specifically? I would say that if you want to make a REST API, that FastAPI is easier and more convenient to use.
After using both Flask and FastAPI extensively I can attest that Flask is the better technology. Flask is extremely stable and has solid organization around them via Pallets. This is a great benefit as they are keeping the ecosystem moving forward and stable.
Versus FastAPI which is lead by a single maintainer which you can search back on HN about opinions on how he's led things.
Flask also has at time of writing only 5 open issues and 6 open PRs, while FastAPI has over 150 PRs open and 40 pages(!) of discussions (which I believe they converted most of their issues to discussions).
Lastly on the technical side, I found Flasks threaded model with a global request context to be really simple to reason about. I'm not totally sold on async Python anymore and encountered odd memory leaks in FastAPI when trying to use it.
flask-openapi3 looks good but has only 246 stars. Would be worried using it in production. flask-pydantic has no openapi tie-in. Oh look, there's me bumping the openapi request that's been an issue since 2020: https://github.com/pallets-eco/flask-pydantic/issues/17 which has an open PR since 2022.
It's possible between Quart and svcs (for DI) and some Pydantic/Marshmallow/OpenAPI extension you might be able to mimic what FastAPI does. But I'd just use FastAPI. I use async too. It's a lot easier to scale in my opinion.
Do none of these pieces matter to you? Like do you not do any data validation or care about OpenAPI?
Dependency injection in fastapi honestly feels like a horrible afterthought. Flask's g is much easier to reason about, and 99% of projects don't need the 'performance improvements' of async.
Flask is old. It's mature, nothing left to add, little if anything remains to fix because nothing is really broken. OTOH its static typing story is pretty weak, and this is likely unfixable by design. Its use of one-letter global objects also feels a bit weird.
It's the "choose boring technology" poster child, of sorts: get things done reliable, without using any design younger than 15 years ago.
