Comment by brokegrammer | Hacker News Reader

Comment by brokegrammer | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com