3 ms·
Other people have already mentioned great things about FastAPI (documentation, data validation, good performance, easy to use, etc). There's also a lot to love
by polyrand 5y ago
Other people have already mentioned great things about FastAPI (documentation, data validation, good performance, easy to use, etc).
There's also a lot to love about Pydantic alone. For me, the best thing about Pydantic is that I get performant, strongly validated objects. When I create Python apps, I try to make sure functions receive and return Pydantic models. That way, if the function does not fail, I'm 100% sure about the data coming in and out. It also saves me from writing many if statements.
Those Pydantic objects can also be dynamically created without losing the data validation parts. By using it, I feel very "secure" about my types and objects, but keeping the simplicity of Python for my whole app.
- travisjungroth 5y agoHave you written it with an ORM backed app? I’m curious if you put the business logic on the Pydantic models and keep the ORM small, or put the logic on the ORM and treat Pydantic like a serializer. Personally, I’d rather work with Pydantic models than ORM.
- sandGorgon 5y agothere's a way to autogenerate pydantic and ORM (sqlalchemy) models from the same python dataclasses. here's a fully functional gist - https://gist.github.com/sandys/671b8b86ba913e6436d4cb22d04b135f https://gist.github.com/sandys/671b8b86ba913e6436d4cb22d04b1...
- madkat 5y agoWe use SQLAlchemy as the ORM layer, but it's very small and most of the work is done with the Pydantic models. It works quite nicely, despite that we loose change tracking, but SQLAlchemy got us covered with merging models.
- polyrand 5y agoI don’t use ORMs. For bigger apps, I use asyncpg and map the results to Pydantic objects. I write raw SQL and keep Pydantic objects as the “source of truth” throughout my app.