FastAPI 0.100.0 release notes
fastapi.tiangolo.com
FastAPI 0.100.0 release notes
1–10 of 115 posts
Re: FastAPI 0.100.0 release notes
#2Did not take long at all to see Pydantic version 2 support. Nice!
Re: FastAPI 0.100.0 release notes
#3> 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.
Re: FastAPI 0.100.0 release notes
#4> 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.
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.
Re: FastAPI 0.100.0 release notes
#5> 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.
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.
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.
Re: FastAPI 0.100.0 release notes
#6Did not take long at all to see Pydantic version 2 support. Nice!
I still can't stand Pydantic's API and its approach to non-documentation. I respect the tremendous amount of hard work that goes into it, but fundamentally I don't like the developer experience and I don't think I'll ever feel otherwise. I use it because my coworkers like it and I've learned its advanced features because I had to in order to get things done, not because I like it.
I would love to see a FastAPI alternative still using Starlette internally, but using Attrs + Marshmallow + Cattrs + Apispec instead of Pydantic. It would be a little less "fast" to write a working prototype, but I'd feel much more comfortable working with those APIs, as well as much more comfortable that my dependencies are well-supported and stable.
The problem of course is not that gluing those things together is hard. The problem is that now someone has put untold hundreds of person-hours into FastAPI, and replicating that level of care, polish, bugfixes, feature requests, etc. is difficult without putting in those hundreds of person-hours yourself.
Re: FastAPI 0.100.0 release notes
#7> 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 reasoning is this? This should be why you use actual semver, and you use the major version to indicate backward compatibility breaking changes, minor versions for new features, and patch versions for bug fixes that don't actually actually change the public API surface.
If you don't want to use semver, just don't use semver.
Re: FastAPI 0.100.0 release notes
#8> 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…
Semver specifically allows you to use 0.x for this purpose: https://semver.org/#spec-item-4
> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
That said, I'd argue that this is a little silly. Maybe a better design is to use something I am calling "zero-calver": 0.YYYY.MM.DD. Then use semantic versioning once stability is reached.
Re: FastAPI 0.100.0 release notes
#9> 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.
Re: FastAPI 0.100.0 release notes
#10> 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.
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.