4 ms·

> In some cases, for pure data validation and processing, you can get performance improvements of 20x or more. This means 2,000% or more. Amazing! Excited to t

> In some cases, for pure data validation and processing, you can get performance improvements of 20x or more. This means 2,000% or more. Amazing! Excited to try it out. Slightly OT: But what are some use-cases where you'd still use Flask over FastAPI? I really like FastAPI's devEx and don't see myself going back to Flask anytime soon. Curious to hear what others think.

LtWorf 3y ago
Well the performance increase is so huge because pydantic1 is really really slow. And for using rust, I'd have expected more tbh… I've been benchmarking pydantic v2 against typedload (which I write) and despite the rust, it still manages to be slower than pure python in some benchmarks. The ones on the website are still about comparing to v1 because v2 was not out yet at the time of the last release. pydantic's author will refuse to benchmark any library that is faster (https://github.com/pydantic/pydantic/pull/3264 https://github.com/pydantic/pydantic/pull/3264 https://github.com/pydantic/pydantic/pull/1525 https://github.com/pydantic/pydantic/pull/1525 https://github.com/pydantic/pydantic/pull/1810 https://github.com/pydantic/pydantic/pull/1810) and keep boasting about amazing performances. On pypy, v2 beta was really really really slow.
- 0cf8612b2e1e 3y ago
  Well that is a bad look. I am sure the highlighted performance metrics have had a lingering impact on library decisions.
- scolvin 3y ago
  This is simply not true. So sad. We removed benchmarks from the docs completely when the rule of "only show benchmarks with comparatively popular or more popular libraries" no longer made sense, and maintaining benchmarks with many hobby packages was obviously going to become burdensome. Please show me a sensible benchmark where your library is faster than pydantic?
  - LtWorf 3y ago
    > This is simply not true. So sad. Ah sorry, so, just coincidentally pydantic happened to be slower than any other library that had a PR to be added to the benchmark, but that was not the reason they were rejected. Better now? > Please show me a sensible benchmark where your library is faster than pydantic? $ python3 perftest/realistic\ union\ of\ objects\ as\ namedtuple.py --pydantic (1.2192879340145737, 1.2595951650291681) $ python3 perftest/realistic\ union\ of\ objects\ as\ namedtuple.py --typedload (1.0874736839905381, 1.114147917018272) I'm not a math genius but I'm fairly sure that 1.08 is less than 1.21. So much for your invite to be gentle and cooperative :D (https://github.com/ltworf/typedload/pull/422 https://github.com/ltworf/typedload/pull/422)
    - scolvin 3y ago
      ¯\_(ツ)_/¯ - I get different results, see the PR.
      - LtWorf 3y ago
        It seems you're running on apple. I really can't reproduce since i don't own one, and unless I get it as a gift I never will. Anyway no server code runs on apple, so it isn't that important to win benchmarks only on apple, I think.
ddorian43 3y ago
You can use gevent and no need to replicate every library under the sun for async io.
0cf8612b2e1e 3y ago
Is it still a bus factor of one? I veer to the side of boring technology and FastAPI is still too in flux for me. I do not ever want to be the vanguard discovering novel problems with my framework.
- v3ss0n 3y ago
  Litestar.dev have a team of dedicated developers , also have similar API to FastAPI. You can watch commit activity and the teamwork.
- nerdponx 3y ago
  Definitely this. Flask is old and well-tested, with a solid feature set and little need to change how it works. Also you'd use Flask for basically anything that isn't an "API", but where you still want something lighter-weight than Django. I believe other traditional Python web frameworks like Pyramid fall into the same category. The "Fast" in FastAPI refers to the speed of getting a working prototype running, specifically for an API that accepts and emits JSON and implements an OpenAPI schema. If that's not your use case, then you might not need or want FastAPI.
aardshark 3y ago
Not to be excessively negative, but this really means very little without more context. Maybe it was very slow before, or it's a particulary unused scenario. I'm always skeptical when people write such praises of their own software without giving a comparison point.
- agent281 3y ago
  Pydantic was a pure python library and was rewritten in Rust recently. To be fair, I have seen some critiques of this rewrite. Specifically saying that the validation model could have been much faster in Python and switching languages papers over the deficiencies. I'm not in a good place to judge if this is true or not.
  - LtWorf 3y ago
    I wrote so in other comments… I was surprised to see that for the benchmarks of my library (typedload), it now manages to win a few… but not all of them.
    - scolvin 3y ago
      would love to see a benchmark where typedload is faster than Pydantic V2. Could you share a link?
      - LtWorf 3y ago
        You realise that you made version2 3 days ago? I re-do the benchmarks of typedload when I make a release. The benchmarks will be updated when the next release happens. I will not do a new release because you need new benchmarks after 3 days. You are free to include benchmarks on your own website (but we both know you won't do that). This is because of how my whole setup works, requiring a git tag and a finished CHANGELOG. Running the command to regenerate the website would cause documentation from the master branch to be published. The benchmarks will be here, as usual. https://ltworf.github.io/typedload/performance.html https://ltworf.github.io/typedload/performance.html I run them just getting the latest available version. But since I can't time travel, I can't get versions from the future to appease you, sorry. I just ran them locally (like you could do by yourself) https://news.ycombinator.com/item?id=36644818 https://news.ycombinator.com/item?id=36644818
WhatsName 3y ago
Coming from django primarily, but written some flask code. I would say the ecosystem. As of my last try, adding authentication (via cookies) to a fastapi project was somewhat cumbersome. Usually as the projects grow, and I start reinventing the wheel, I come to regret not going for a "full" framework.
gsa 3y ago
Flask has been around much longer than FastAPI and, as a result, is a much more mature framework. Some examples: - There's a memory leak with a particular combination of packages FastAPI [0] - Before Pydantic v2, you would validate your data on input (when it's stored in the db) and then every single time on retrieval. There is no way to skip validation, for example, when you are generating a response on data that was already validated when it was persisted to the db. [1] - FastAPI has documentation only in the form of tutorials. There is no API documentation and if something is not clear looking through the source code is the only option - You need ORJSON for maximum serialisation performance (perhaps this has changed with Pydantic v2) [2] - Using FastAPI with uvicorn doesn't respect log format settings [3] I don't mean to imply that FastAPI is a bad framework. The Flask ecosystem has had over a decade to mature. FastAPI and the ecosystem will get there but it _needs_ time. - [0] https://github.com/tiangolo/fastapi/discussions/9082 https://github.com/tiangolo/fastapi/discussions/9082 - [1] https://github.com/pydantic/pydantic/issues/1212 https://github.com/pydantic/pydantic/issues/1212 - [2] https://fastapi.tiangolo.com/advanced/custom-response/#use-orjsonresponse https://fastapi.tiangolo.com/advanced/custom-response/#use-o... - [3] https://github.com/encode/uvicorn/issues/527 https://github.com/encode/uvicorn/issues/527
- minimaxir 3y ago
  > - You need ORJSON for maximum serialisation performance (perhaps this has changed with Pydantic v2) [2] The common orjson trick no longer works in v2 and will throw warnings, but it appears it's no longer necessary since the JSON formatting leverages the native seralizer which happens in Rust-land.
- arun-mani-j 3y ago
  Exactly my issue too. Why there is no API documentation for FastAPI? It is very difficult to know what is available and what is not beyond the tutorial style docs. (I love FastAPI and use it for all my projects, this one little thing troubles me sometimes)

LtWorf 3y ago

Well the performance increase is so huge because pydantic1 is really really slow. And for using rust, I'd have expected more tbh… I've been benchmarking pydantic v2 against typedload (which I write) and despite the rust, it still manages to be slower than pure python in some benchmarks. The ones on the website are still about comparing to v1 because v2 was not out yet at the time of the last release. pydantic's author will refuse to benchmark any library that is faster (https://github.com/pydantic/pydantic/pull/3264 https://github.com/pydantic/pydantic/pull/3264 https://github.com/pydantic/pydantic/pull/1525 https://github.com/pydantic/pydantic/pull/1525 https://github.com/pydantic/pydantic/pull/1810 https://github.com/pydantic/pydantic/pull/1810) and keep boasting about amazing performances. On pypy, v2 beta was really really really slow.

0cf8612b2e1e 3y ago
Well that is a bad look. I am sure the highlighted performance metrics have had a lingering impact on library decisions.
scolvin 3y ago
This is simply not true. So sad. We removed benchmarks from the docs completely when the rule of "only show benchmarks with comparatively popular or more popular libraries" no longer made sense, and maintaining benchmarks with many hobby packages was obviously going to become burdensome. Please show me a sensible benchmark where your library is faster than pydantic?
- LtWorf 3y ago
  > This is simply not true. So sad. Ah sorry, so, just coincidentally pydantic happened to be slower than any other library that had a PR to be added to the benchmark, but that was not the reason they were rejected. Better now? > Please show me a sensible benchmark where your library is faster than pydantic? $ python3 perftest/realistic\ union\ of\ objects\ as\ namedtuple.py --pydantic (1.2192879340145737, 1.2595951650291681) $ python3 perftest/realistic\ union\ of\ objects\ as\ namedtuple.py --typedload (1.0874736839905381, 1.114147917018272) I'm not a math genius but I'm fairly sure that 1.08 is less than 1.21. So much for your invite to be gentle and cooperative :D (https://github.com/ltworf/typedload/pull/422 https://github.com/ltworf/typedload/pull/422)
  - scolvin 3y ago
    ¯\_(ツ)_/¯ - I get different results, see the PR.
    - LtWorf 3y ago
      It seems you're running on apple. I really can't reproduce since i don't own one, and unless I get it as a gift I never will. Anyway no server code runs on apple, so it isn't that important to win benchmarks only on apple, I think.

ddorian43 3y ago

You can use gevent and no need to replicate every library under the sun for async io.

0cf8612b2e1e 3y ago

Is it still a bus factor of one? I veer to the side of boring technology and FastAPI is still too in flux for me. I do not ever want to be the vanguard discovering novel problems with my framework.

v3ss0n 3y ago
Litestar.dev have a team of dedicated developers , also have similar API to FastAPI. You can watch commit activity and the teamwork.
nerdponx 3y ago
Definitely this. Flask is old and well-tested, with a solid feature set and little need to change how it works. Also you'd use Flask for basically anything that isn't an "API", but where you still want something lighter-weight than Django. I believe other traditional Python web frameworks like Pyramid fall into the same category. The "Fast" in FastAPI refers to the speed of getting a working prototype running, specifically for an API that accepts and emits JSON and implements an OpenAPI schema. If that's not your use case, then you might not need or want FastAPI.

aardshark 3y ago

Not to be excessively negative, but this really means very little without more context. Maybe it was very slow before, or it's a particulary unused scenario. I'm always skeptical when people write such praises of their own software without giving a comparison point.

agent281 3y ago
Pydantic was a pure python library and was rewritten in Rust recently. To be fair, I have seen some critiques of this rewrite. Specifically saying that the validation model could have been much faster in Python and switching languages papers over the deficiencies. I'm not in a good place to judge if this is true or not.
- LtWorf 3y ago
  I wrote so in other comments… I was surprised to see that for the benchmarks of my library (typedload), it now manages to win a few… but not all of them.
  - scolvin 3y ago
    would love to see a benchmark where typedload is faster than Pydantic V2. Could you share a link?
    - LtWorf 3y ago
      You realise that you made version2 3 days ago? I re-do the benchmarks of typedload when I make a release. The benchmarks will be updated when the next release happens. I will not do a new release because you need new benchmarks after 3 days. You are free to include benchmarks on your own website (but we both know you won't do that). This is because of how my whole setup works, requiring a git tag and a finished CHANGELOG. Running the command to regenerate the website would cause documentation from the master branch to be published. The benchmarks will be here, as usual. https://ltworf.github.io/typedload/performance.html https://ltworf.github.io/typedload/performance.html I run them just getting the latest available version. But since I can't time travel, I can't get versions from the future to appease you, sorry. I just ran them locally (like you could do by yourself) https://news.ycombinator.com/item?id=36644818 https://news.ycombinator.com/item?id=36644818

WhatsName 3y ago

Coming from django primarily, but written some flask code. I would say the ecosystem. As of my last try, adding authentication (via cookies) to a fastapi project was somewhat cumbersome. Usually as the projects grow, and I start reinventing the wheel, I come to regret not going for a "full" framework.

gsa 3y ago

Flask has been around much longer than FastAPI and, as a result, is a much more mature framework. Some examples: - There's a memory leak with a particular combination of packages FastAPI [0] - Before Pydantic v2, you would validate your data on input (when it's stored in the db) and then every single time on retrieval. There is no way to skip validation, for example, when you are generating a response on data that was already validated when it was persisted to the db. [1] - FastAPI has documentation only in the form of tutorials. There is no API documentation and if something is not clear looking through the source code is the only option - You need ORJSON for maximum serialisation performance (perhaps this has changed with Pydantic v2) [2] - Using FastAPI with uvicorn doesn't respect log format settings [3] I don't mean to imply that FastAPI is a bad framework. The Flask ecosystem has had over a decade to mature. FastAPI and the ecosystem will get there but it _needs_ time. - [0] https://github.com/tiangolo/fastapi/discussions/9082 https://github.com/tiangolo/fastapi/discussions/9082 - [1] https://github.com/pydantic/pydantic/issues/1212 https://github.com/pydantic/pydantic/issues/1212 - [2] https://fastapi.tiangolo.com/advanced/custom-response/#use-orjsonresponse https://fastapi.tiangolo.com/advanced/custom-response/#use-o... - [3] https://github.com/encode/uvicorn/issues/527 https://github.com/encode/uvicorn/issues/527

minimaxir 3y ago
> - You need ORJSON for maximum serialisation performance (perhaps this has changed with Pydantic v2) [2] The common orjson trick no longer works in v2 and will throw warnings, but it appears it's no longer necessary since the JSON formatting leverages the native seralizer which happens in Rust-land.
arun-mani-j 3y ago
Exactly my issue too. Why there is no API documentation for FastAPI? It is very difficult to know what is available and what is not beyond the tutorial style docs. (I love FastAPI and use it for all my projects, this one little thing troubles me sometimes)