4 ms·
I too have made similar observations regarding pydantic and FastAPI. I was evaluating various Python async http frameworks and landed on a similar stack: - at
by willhoyle 3y ago
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 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>
- willhoyle 3y agoThis looks like exactly what I've been looking for. I just want strong typing, json <-> struct and validation. Seems like it ticks all the boxes + speed benefits which is always nice. I especially find it useful that I can use messagepack for internal service chatter but still support json for external stuff and dump astuple to sqlite.
- eyegor 3y agoDepending 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 other python web frameworks.
- jammycrisp 3y ago+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. [1]: https://litestar.dev/ https://litestar.dev/ [2]: https://github.com/jcrist/msgspec https://github.com/jcrist/msgspec [3]: https://www.attrs.org/en/stable/ https://www.attrs.org/en/stable/
- nerdponx 3y agoI 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.
- jammycrisp 3y agostarlite was the original name, it was recently renamed to litestar due to comments about how easily confused "starlette" and "starlite" are.
- d0mine 3y agodata point in favor of the renaming: while reading GP, I've assumed that "starlite" is a typo for "starlette."