4 ms·

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 "HyperF

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"

falcor84 1y ago
But this is about html rather than API endpoints; Flask seems like a much more appropriate choice.
nop_slide 1y ago
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. https://palletsprojects.com/ https://palletsprojects.com/ 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.
- odie5533 1y ago
  Flask is missing... pydantic, dependency injection, openapi, swagger, real async.
  - nop_slide 1y ago
    https://github.com/pallets-eco/flask-pydantic https://github.com/pallets-eco/flask-pydantic https://luolingchun.github.io/flask-openapi3/v4.x/ https://luolingchun.github.io/flask-openapi3/v4.x/ > dependency injection While nice I never found this to be a critical deciding factor of using a technology. > real async If you really want it there is Quart which is real async https://github.com/pallets/quart https://github.com/pallets/quart I'm not a huge async fan in python anymore so not it's not a huge issue for me. But there are definitely options for Flask if you want to use async.
    - odie5533 1y ago
      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 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?
      - nop_slide 1y ago
        At $JOB we're using both flask-pydantic and flask-openapi via those libraries and they are serving us just fine. But yes async does not matter to me.
    - wiseowise 1y ago
      Of course you can assemble FastAPI scrim scratch, that’s not the point. The selling point is everything integrated, like Django.
  - Exoristos 1y ago
    So nothing of importance.
    - odie5533 1y ago
      What do you do for data validation?
  - callamdelaney 1y ago
    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.
- nine_k 1y ago
  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.
rapfaria 1y ago
Is FastAPI still (micro)managed by one person?
- mrits 1y ago
  I’ve never heard micromanaged used in this positive context
  - rolisz 1y ago
    It's not positive
- langitbiru 1y ago
  He got funding. So, I guess he can hire some people to help him. https://www.sequoiacap.com/article/partnering-with-fastapi-labs-simplified-app-deployment/ https://www.sequoiacap.com/article/partnering-with-fastapi-l...
brokegrammer 1y ago
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.
- graemep 1y ago
  > 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.
  - brokegrammer 1y ago
    > 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.

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"

falcor84 1y ago

But this is about html rather than API endpoints; Flask seems like a much more appropriate choice.

nop_slide 1y ago

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. https://palletsprojects.com/ https://palletsprojects.com/ 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.

odie5533 1y ago
Flask is missing... pydantic, dependency injection, openapi, swagger, real async.
- nop_slide 1y ago
  https://github.com/pallets-eco/flask-pydantic https://github.com/pallets-eco/flask-pydantic https://luolingchun.github.io/flask-openapi3/v4.x/ https://luolingchun.github.io/flask-openapi3/v4.x/ > dependency injection While nice I never found this to be a critical deciding factor of using a technology. > real async If you really want it there is Quart which is real async https://github.com/pallets/quart https://github.com/pallets/quart I'm not a huge async fan in python anymore so not it's not a huge issue for me. But there are definitely options for Flask if you want to use async.
  - odie5533 1y ago
    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 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?
    - nop_slide 1y ago
      At $JOB we're using both flask-pydantic and flask-openapi via those libraries and they are serving us just fine. But yes async does not matter to me.
  - wiseowise 1y ago
    Of course you can assemble FastAPI scrim scratch, that’s not the point. The selling point is everything integrated, like Django.
- Exoristos 1y ago
  So nothing of importance.
  - odie5533 1y ago
    What do you do for data validation?
- callamdelaney 1y ago
  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.
nine_k 1y ago
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.

rapfaria 1y ago

Is FastAPI still (micro)managed by one person?

mrits 1y ago
I’ve never heard micromanaged used in this positive context
- rolisz 1y ago
  It's not positive
langitbiru 1y ago
He got funding. So, I guess he can hire some people to help him. https://www.sequoiacap.com/article/partnering-with-fastapi-labs-simplified-app-deployment/ https://www.sequoiacap.com/article/partnering-with-fastapi-l...

brokegrammer 1y ago

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.

graemep 1y ago
> 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.
- brokegrammer 1y ago
  > 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.