Earlier 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…
If 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. I…
FastAPI 0.100.0 release notes
51–60 of 115 posts
Re: FastAPI 0.100.0 release notes
#52https://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-...
Re: FastAPI 0.100.0 release notes
#53I'm really curious about why you would want to use FastAPI over Django Rest Framework. Are there signficant advantages to FastAPI?
All from a few lines of code.
But I've mostly switched to django-ninja which is more type safe and faster.
Re: FastAPI 0.100.0 release notes
#54https://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-...
Re: FastAPI 0.100.0 release notes
#55https://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-...
Re: FastAPI 0.100.0 release notes
#56> 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…
This is semver: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. (from https://semver.org/ )
Re: FastAPI 0.100.0 release notes
#57Earlier quoted context omitted.
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 altern…
Could you simplify your point? I was an ardent marshmallow user and when I finally switched to pydantic, it felt like I finally sat down in my life after standing forever. The documentation sounds good enough to me, but importantly the interface pydantic provides to define your json schema is the most elegant interface I’ve seen in any language and miles better than the mess marshmallow provided. For many of us espec…
The API is a little weird, particularly around defining validators. The parameter name-matching is an "interesting" design choice. Accessing "values" as a dict[str,Any] is messy if you care about static typing, although I can understand why they did it.
Furthermore, the behavior of validators and the exact sequence in which they run is not defined by the docs. It's not that hard to figure out, but it also might change at any time because there's no user contract. Attrs is significantly nicer in just about all respects here, especially their attention to detail in their extensive user guide and reference docs.
Speaking of user contract, there's no clear separation between private and public. Without a reference doc it all looks like fair game, but without a reference doc it also might all change at any moment. Either you stick to the examples, or you're off doing a guess-and-check dance and hoping something doesn't break.
Even with the Mypy plugin, I often have to write `if TYPE_CHECKING` all over any nontrivial Pydantic class consuming data from external sources. Variable annotations in Pydantic are fundamentally not PEP 484 type hints. That's fine, but it's confusing that they're almost the same, and, as above, it's almost entirely up to you to figure out how it all works, either by trial and error or by digging around in the issue tracker and StackOverflow.
Ease of writing and reliability is precisely my big area of annoyance and concern. Speed of (de)serialization is comparatively unimportant (although I don't like the huge amount of overhead involved and I avoid using it in hot code paths).
I also don't like using Pydantic-defined classes very much, because the actual init method signature is just *args, **kwargs, which doesn't work well with any tooling. It feels like being back in the Tornado & PyMongo dark ages where everything is dynamic or dynamically-generated and classes are just glorified hash tables.
I agree that the JSONSchema integration is outstanding. BaseSettings is also a tremendous productivity improvement, I love that I can define a class and immediately get a proper app-wide config reading from both env vars and a dotenv file. I also like the default error messages that tell you exactly which field failed validation. I also like the validator system (once I figured out how it worked), respecting the order in which I define the validators as well as supporting validators that run before or after the default set of validators (pre=True and pre=False respectively). I was probably being a little too negative before, but my annoyance level with the developer-facing API and documentation remains high, and I will gladly jump to an Attrs-based alternative as soon as one exists.*
Re: FastAPI 0.100.0 release notes
#58https://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-...
How does it compare to Starlette? (lib FastAPI uses under the hood) I've used vanilla Starlette for recent projects and it's been great.
Starlette can be considered pure server framework in the lines of CherryPy, wezurg in wsgi/sync world.
Litestar is a lot more battery included with built-in integration to Sqalchemy, many other ORMs as plugin. Built-in security and authentication middleware.
Join our discord, we have good community there too .
Re: FastAPI 0.100.0 release notes
#59https://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-...
I 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
Re: FastAPI 0.100.0 release notes
#60https://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-...
Nice, thanks. I wonder how performance compares to django-ninja.