[dead]
FastAPI 0.100.0 release notes
31–40 of 115 posts
Re: FastAPI 0.100.0 release notes
#32> 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.
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/1525 https://github.com/pydantic/pydantic/pull/1810) and keep boasting about amazing performances.
On pypy, v2 beta was really really really slow.
Re: FastAPI 0.100.0 release notes
#33> 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.
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.
Yes it was incredibly slow and inefficient.
I maintain typedload (a similar project, that I started before pydantic's first release) and pydantic 2 somehow still manages to be slower than a pure python library that got no funding to improve performances.
Re: FastAPI 0.100.0 release notes
#34Earlier quoted context omitted.
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.
> Maybe it was very slow before That is at least partly the case. I maintain msgspec[1], another Python JSON validation library. Pydantic V1 was ~100x slower at encoding/decoding/validating JSON than msgspec, which was more a testament to Pydantic's performance issues than msgspec's speed. Pydantic V2 is definitely faster than V1, but it's still ~10x slower than msgspec, and up to 2x slower than other pure-python imp…
Eeey hello :D
Eeh come on, I think it's a bit unfair to compare, because msgspec doesn't support regular python union types… which are the number 1 source of slowness… at least in my real world use case of the thing. I've got hundreds of classes with abundant nesting and unions.
In pydantic v2 they did the same thing i've been doing in typedload for a few versions already: check the field annotated with a Literal and directly pick the correct type, rather than do try and error. So now the speed for unions has become better.
Even so, for being binary vs pure python, I'd have expected much more.
Re: FastAPI 0.100.0 release notes
#35Earlier quoted context omitted.
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.
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.
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.
Re: FastAPI 0.100.0 release notes
#36> 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.
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 autho…
Well that is a bad look. I am sure the highlighted performance metrics have had a lingering impact on library decisions.
Re: FastAPI 0.100.0 release notes
#37Earlier quoted context omitted.
I too have made similar observations regarding pydantic and FastAPI. I was evaluating various Python async http frameworks and landed on a similar stack: - attrs/cattrs for models - starlette+uvicorn for HTTP/websocket - validation I’m still on the fence about. I’ll see how far I get with the built in validators offered by attrs. I use voluptuous at work and generally like the DX but it’s in maintenance mode. This is…
Depending on how far in you are, starlite/litestar has good documentation and offers another "batteries included" framework. Performance wise it's about the same and the stack is about the same. Fastapi suffers from the "one solo dev in Nebraska" paradigm (check out open prs and old tickets). For me the main draw of litestar is the batteries + better docs + more active development with multiple developers vs most oth…
+1 for litestar[1]. The higher bus-factor is nice, and I like that they're working to embrace a wider set of technologies than just pydantic. The framework currently lets you model objects using msgspec[2] (they actually use msgspec for all serialization), pydantic, or attrs[3], and the upcoming release adds some new mechanisms for handling additional types. I really appreciate the flexibility in modeling APIs; not everything fits well into a pydantic shaped box.
Re: FastAPI 0.100.0 release notes
#38Earlier quoted context omitted.
I too have made similar observations regarding pydantic and FastAPI. I was evaluating various Python async http frameworks and landed on a similar stack: - attrs/cattrs for models - starlette+uvicorn for HTTP/websocket - validation I’m still on the fence about. I’ll see how far I get with the built in validators offered by attrs. I use voluptuous at work and generally like the DX but it’s in maintenance mode. This is…
Depending on how far in you are, starlite/litestar has good documentation and offers another "batteries included" framework. Performance wise it's about the same and the stack is about the same. Fastapi suffers from the "one solo dev in Nebraska" paradigm (check out open prs and old tickets). For me the main draw of litestar is the batteries + better docs + more active development with multiple developers vs most oth…
I haven't heard of Starlite or Litestar before. Is one a fork of the other? Their documentation intro text is identical:
> {Litestar|Starlite} is a powerful, flexible, highly performant, and opinionated ASGI framework, offering first class typing support and a full Pydantic integration. > > The {Litestar|Starlite} framework supports Plugins, ships with dependency injection, security primitives, OpenAPI schema generation, MessagePack, middlewares, and much more.
Re: FastAPI 0.100.0 release notes
#39> FastAPI is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly. New features are added frequently, bugs are fixed regularly, and the code is still continuously improving. That's why the current versions are still 0.x.x, this reflects that each version could potentially have breaking changes.[1] What kind of weird reaso…
I prefer straight integer version numbers.
It's a tendency of developers to make things complex.
Re: FastAPI 0.100.0 release notes
#40Earlier quoted context omitted.
Depending on how far in you are, starlite/litestar has good documentation and offers another "batteries included" framework. Performance wise it's about the same and the stack is about the same. Fastapi suffers from the "one solo dev in Nebraska" paradigm (check out open prs and old tickets). For me the main draw of litestar is the batteries + better docs + more active development with multiple developers vs most oth…
I haven't heard of Starlite or Litestar before. Is one a fork of the other? Their documentation intro text is identical: > {Litestar|Starlite} is a powerful, flexible, highly performant, and opinionated ASGI framework, offering first class typing support and a full Pydantic integration. > > The {Litestar|Starlite} framework supports Plugins, ships with dependency injection, security primitives, OpenAPI schema generat…
starlite was the original name, it was recently renamed to litestar due to comments about how easily confused "starlette" and "starlite" are.