10 ms·
FastAPI 0.100.0 release notes
- The_Hoff 3y agoFastAPI is a joy to use. Tried using `bump-pydantic` and it worked flawlessly. Thankful for the work by this team.
- nikcub 3y agoThe rustification of Python libraries and tooling continues and it has been brilliant. In the past 6 months I have personally switched projected to ruff[0], polars and now - as of this morning[1] - pydantic 2 and FastAPI 0.100 [0] has replaced pylint, flake8, pyupgrade, isort, mccabe and pydocstyle [1] bump-pydantic worked well, after porting settings to pydantic_settings.
- Kydlaw 3y agoYou might want to check Pylyzer then (https://github.com/mtshiba/pylyzer https://github.com/mtshiba/pylyzer). I'm not involved at all. It is still very very early in development. But as it is in the same vein, I thought I'd mentioned it here.
- tomtom1337 3y agoHave you actually got it working as an LSP server? I tried about a month ago without success. Edit: Scratch that, had a go now with no trouble, passing `pylyzer --server` from my editor (helix).
- LtWorf 3y agoAt the cost of bigger downloads, not working with other python implementations, and in the case of pydantic, the performance gains aren't that impressive compared to pure python libraries.
- guender 3y ago[dead]
- v3ss0n 3y agohttps://litestar.dev https://litestar.dev is also reaching 2.0 .it is a lot faster than FastAPI yet much better maintained. Has DTO, event and channels, Repository, Service DDD style framework built-in. No promotional commits. I had written the reason of moving away from FastApi here and intro to Litestar 2.0. https://dev.to/v3ss0n/litestar-20-beta-speed-of-light-power-of-stars-1j62 https://dev.to/v3ss0n/litestar-20-beta-speed-of-light-power-...
- winrid 3y agoNice, thanks. I wonder how performance compares to django-ninja.
- v3ss0n 3y agoWe haven't test Django ninja in term of performance. But from our experience of Django 4.2 async , Django isn't truly asynchronous yet. Since ecosystem is not asynchronous I am not sure how asynchronous API would benefit from that when the extension aren't.
- lyu07282 3y agoI think you raised some valid concerns there, I see 18 open issues in the fastapi repo, what's going on there? Are they just moving everything into a discussion? A bit concerning
- v3ss0n 3y agoThere are thousands of issues which about 30% of them are actual bugs, including some of them are those we found on production and reported, the maintainer wrote a script that convert all to discussion and never looked back, so we never look back too.
- holler 3y agoHow does it compare to Starlette? (lib FastAPI uses under the hood) I've used vanilla Starlette for recent projects and it's been great.
- miiiiiike 3y agoI wish Django would take async more seriously. This comment gives a pretty good overview of the current situation (some points are more valid than others): https://github.com/encode/django-rest-framework/discussions/7774#discussioncomment-6361530 https://github.com/encode/django-rest-framework/discussions/... The Python ecosystem is strange. Where other dev communities will embrace new ways of doing things faster than most people can keep up — the Python community needs to be pulled kicking and screaming into the light once ever decade or so. Python 2 to 3, ~10 years. async/await has been in Python since 2015, it feels like it's going to be another 5 years before we see people taking async seriously in the big packages. Same problem we had during the 2/3 transition. No library support, no developer support.
- andrewstuart 3y agoHave a look at Starlette, it’s by the guy who made Django. FastAPI is built on Starlette and adds more batteries included. If you’re interested in async you’re far better off to go async native than with a framework that’s synchronous. Asyncpg is the fastest Python Postgres driver there is, works well with sanic, Starlette or FastAPI.
- henry_viii 3y agoCorrection: Starlette is made by the guy who made the Django REST Framework, not Django. DRF is a separate project from Django.
- andrewstuart 3y agoThanks.
- miiiiiike 3y agoThe Starlette dev is the founder of Django Rest Framework.. Which is my least favorite part of working with Django. I really wish Django shipped with its own REST Framework. I’ve been keeping an eye on FastAPI, Starlette, and a few other libraries but, compared to Django, they’re mostly powered by hype. I found a bunch of Pydantic bugs 2(3?)+ years ago that are only now getting addressed in v2.
- monlockandkey 3y agoMy only frustration with fastapi is the lack of API documentation. Usually docs just have API specified, this project goes the other end of the spectrum and has examples for everything. Whilst that is nice, APIs are undocumented and it is a bit harder to grok the project without the available functions and methods in a list
- andrewstuart 3y agoThis project has 433 pull requests. It used to have literally thousands of open issues. Where did they go? Fixed? It also had a project owner who refused to form a team of people responsible for the project. How did that pan out?
- greazy 3y agoNot long ago the lead author converted all issues to discussions. I think most of the issues were actually questions.
- andrewstuart 3y agoOver 14 years or so I’ve developed major applications with flask, bottle, Falcon, FastAPI, Django, Sanic and Starlette. My preferred back end web server is now nodejs with typescript and plain old Postgres SQL queries, no ORM. Caddy web server with auth sub requests.
- v3ss0n 3y agoTraefik would be much better proxy if you are using container based dev. Also Please give litestar a try.
- andrewstuart 3y agoI’m not a fan of the complexity of containers or kubernetes. Everything I’ve built scales vertically on bare OS very nicely. Regarding litestar, if I wanted to do Python web development I’d use Starlette, which I really liked, but I’ll probably stick with nodejs and typescript from here for web applications.
- btreecat 3y agoGreat, so we just gotta "ship your bare OS" to prod. That's exactly what a container is for. Container is just a logical isolation tool that works at the distribution/deployment level.
- v3ss0n 3y ago> Great, so we just gotta "ship your bare OS" to prod. Back in 2008 , We ship by DDing the whole disk :D
- andrewstuart 3y agoWhat’s wrong with shipping source code? Containers add huge complexity, for what?
- braza 3y ago
- svaha1728 3y agoDid not take long at all to see Pydantic version 2 support. Nice!
- nerdponx 3y agoI 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.
- willhoyle 3y agoI 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 purely personally preference, I’m sure devs using fastapi+pydantic are more productive in the long run. It almost feels like I’m hand rolling my own fastapi implementation but at the same time I don’t want to be too locked in to frameworks like that. Ive been burnt by magic frameworks that do too much behind the scenes and there’s something nice about fully understanding what’s going on when you hand stitch libraries yourself.
- jammycrisp 3y agoIf you like cattrs, you _might_ be interested in trying out my msgspec library [1]. It works out-of-the-box with attrs objects (as well as its own faster `Struct` types), while being ~10-15x faster than cattrs for encoding/decoding/validating JSON. The hope is it's easy to integrate msgspec with other tools (like attrs!) rather than forcing the user to rewrite code to fit the new validation/serialization framework. It may not fit every use case, but if msgspec works for you it should be generally an order-of-magnitude faster than other Python options. [1]: https://github.com/jcrist/msgspec https://github.com/jcrist/msgspec </blatant-evangelism>
- krat0sprakhar 3y ago> 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 agoWell 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 agoWell that is a bad look. I am sure the highlighted performance metrics have had a lingering impact on library decisions.
- scolvin 3y agoThis 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
- TheRealPomax 3y ago> 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. [1] https://fastapi.tiangolo.com/deployment/versions/ https://fastapi.tiangolo.com/deployment/versions/
- deleted 3y ago[deleted]
- foolswisdom 3y agoFWIW other frameworks (namely, flask) took a similar approach of not moving to 1.0 for a while.
- palata 3y agoWhich sucks, to be honest. Just accept that your major can go up to 23.8.3, and it does not make it less professional than 0.231.0. Actually it's better because it said which releases broke backward compatibility and which ones did not.
- norgie 3y agoSeriously, this 0ver nonsense makes it so much harder to deal with upgrading packages. Who cares you bump the major version frequently
- the__alchemist 3y agoFastAPI doesn't use Semver; it uses ZeroVer: https://0ver.org/ https://0ver.org/
- aliljet 3y agoI'm really curious about why you would want to use FastAPI over Django Rest Framework. Are there signficant advantages to FastAPI?
- pedrovhb 3y agoThey're totally different in terms of the scope of the project they're meant to be used for. FastAPI is much closer to Flask in that it's trivial to throw up a single file with a couple of routes, and you can use something like SQLite yourself for persistence to disk, or install a couple of libraries for authentication or such (not sure if that's built in by now). Django, on the other hand, requires a multi-step process to even start a project and creates a dozen of files, most of which are boilerplate, before you can even see a "hello world" route. But in exchange, you get not just a program which deals with routing and templates and status codes, but much more - a world-class ORM which integrates pretty much transparently with multiple data stores like Postgres or SQLite, an amazing dashboard out of the box which is really handy for sharing with non-techies, a very mature ecosystem, and perhaps most importantly, the "one right way to do things", which makes it a lot more effective for collaboration between a bunch of engineers. It's of course not infallible, has a learning curve, and comes with a good few footguns that get the uninitiated, but the upside is a real upside. Migrations alone might justify it - for all the grief of merge conflicts between migrations right before a code freeze, I can't imagine how much worse it would be to not have them. So I wouldn't say there's significant advantages to using either - they're different tools for different use cases. If you want to get something up quick that isn't too complex, FastAPI is great for that. If you know you're eventually going to rewrite Django but worse, you may as well use the real thing.
- winrid 3y agoI found DRF to be great at generating fairly simple APIs very quickly. But complicated stuff gets... more complicated, due to inheritance and magic. I love me some DRF, govscent uses it: https://govscent.org/api/ https://govscent.org/api/ All from a few lines of code. But I've mostly switched to django-ninja which is more type safe and faster.
- djaychela 3y agoI've just made a first project in fastAPI, and it was trivially simple compared to my previous adventures in DRF. Plus asyc from the get go, which was also pleasant. I had a task as part of this that takes 10 seconds to run, and there's a built in way to allow it to run in the background. And the documentation is excellent.