3 ms·

Thanks for FastAPI. It's a super exciting project. As a very long time Django developer I see the potential for it to finally replace Django in jamstack-type a

Thanks for FastAPI. It's a super exciting project. As a very long time Django developer I see the potential for it to finally replace Django in jamstack-type apps. But two things are direly missing for that to be the default IMO: 1. A flexible admin. Django's admin allows for super fast prototyping. I wrote an accounting/bookkeeping app recently which I used for myself, and I didn't write a UI for it at all for several months because I could just get by with the admin. (Filed two quarterlies with just the admin as UI!) 2. An ORM that is as natural as Django's. I love SQLAlchemy but its syntax is a huge turnoff. I imagine the "right solution" combines the best of both worlds; maybe some Django-like syntax wrapper around SQLAlchemy. … with typings. What do you think, is there progress in those areas?

Townley 6y ago
Also a big django fan taking the plunge (we've started using FastAPI in production at work, and really love it!) An admin interface would be wonderful, but given such a heavy API focus, I find Insomnia or Postman to work well enough for those interactions, so I haven't missed it all that much. Seconding the SQLAlchemy friction though. Built-in ORM support would really help cut down the boilerplate required to wire FastAPI/Starlette models into the database. I think django devs feel the issue more acutely since defining FastAPI objects feels so familiar to making django models. But at the end, rather than having to wire up DRF serializers and viewsets, you need to wire up the database. One other benefit to taking a more opinionated approach to database interactions: with a sensible-defaults-but-customizable user model, FastAPI could offer token based authentication/authorization out of the box by implementing something similar to Django+DRF+Djoser endpoints Anyway, seconding the gratitude for this wonderful project, and really looking forward to using it more!
- tiangolo 6y ago
  I don't know Djoser, but simpler utilities for auth and more docs with more examples are certainly planned. :)
wbadart 6y ago
Re #1, I haven't used it before but there is https://github.com/tiangolo/full-stack-fastapi-postgresql https://github.com/tiangolo/full-stack-fastapi-postgresql Looks like it includes the kind of admin dashboard you'd get with Django.
- tiangolo 6y ago
  Yep, that's the intention. But it's a frontend written by hand, and has to be updated by hand. An automatic admin UI based on OpenAPI is one of the plans I have for the future. :)
wp381640 6y ago
I think the idea is that FastAPI does one thing and does it well. You can mix in other parts of what you need, in the same way FastAPI itself leans on great projects. SQLAlchemy + Alembic are standard because they're robust and well-know, but there are alternatives (particularly with async)[0][1][2] For admin you can FE it with something like react-admin which has pluggable data providers, or api-admin[4] [0] https://github.com/tortoise/tortoise-orm https://github.com/tortoise/tortoise-orm [1] https://ponyorm.org/ https://ponyorm.org/ [2] https://github.com/encode/orm https://github.com/encode/orm [3] https://github.com/api-platform/admin https://github.com/api-platform/admin
- CameronNemo 6y ago
  Is wtforms still in use?
  - wp381640 6y ago
    using pydantic pretty much everywhere.
tiangolo 6y ago
Ha! You just described 2 of the main future projects I have planned! 1. An admin UI based on OpenAPI, which makes it independent of DB. 2. A mix between Pydantic and SQLAlchemy, to use the same Pydantic model for both (I have some experiment in progress). I just need to find the time for it all, but it's certainly planned.
- lukasm 6y ago
  > A mix between Pydantic and SQLAlchemy, to use the same Pydantic model for both (I have some experiment in progress). I'm not if it's a good idea. If app is more complex than a TODO you end up with a few way to serialise the same DB model. You have a few schemas to update User in the DB, serlize into the queue without password etc.
uranusjr 6y ago
> I love SQLAlchemy but its syntax is a huge turnoff. Out of curiosity, which part of the syntax? (Hopefully not all of it.) Personally I hate the declarative part (defining the model), but feel the query syntax is good, especially with some SQL knowledge (Django’s isn’t bad either but is too divorced to the SQL syntax to me).

Townley 6y ago

Also a big django fan taking the plunge (we've started using FastAPI in production at work, and really love it!) An admin interface would be wonderful, but given such a heavy API focus, I find Insomnia or Postman to work well enough for those interactions, so I haven't missed it all that much. Seconding the SQLAlchemy friction though. Built-in ORM support would really help cut down the boilerplate required to wire FastAPI/Starlette models into the database. I think django devs feel the issue more acutely since defining FastAPI objects feels so familiar to making django models. But at the end, rather than having to wire up DRF serializers and viewsets, you need to wire up the database. One other benefit to taking a more opinionated approach to database interactions: with a sensible-defaults-but-customizable user model, FastAPI could offer token based authentication/authorization out of the box by implementing something similar to Django+DRF+Djoser endpoints Anyway, seconding the gratitude for this wonderful project, and really looking forward to using it more!

tiangolo 6y ago
I don't know Djoser, but simpler utilities for auth and more docs with more examples are certainly planned. :)

wbadart 6y ago

Re #1, I haven't used it before but there is https://github.com/tiangolo/full-stack-fastapi-postgresql https://github.com/tiangolo/full-stack-fastapi-postgresql Looks like it includes the kind of admin dashboard you'd get with Django.

tiangolo 6y ago
Yep, that's the intention. But it's a frontend written by hand, and has to be updated by hand. An automatic admin UI based on OpenAPI is one of the plans I have for the future. :)

wp381640 6y ago

I think the idea is that FastAPI does one thing and does it well. You can mix in other parts of what you need, in the same way FastAPI itself leans on great projects. SQLAlchemy + Alembic are standard because they're robust and well-know, but there are alternatives (particularly with async)[0][1][2] For admin you can FE it with something like react-admin which has pluggable data providers, or api-admin[4] [0] https://github.com/tortoise/tortoise-orm https://github.com/tortoise/tortoise-orm [1] https://ponyorm.org/ https://ponyorm.org/ [2] https://github.com/encode/orm https://github.com/encode/orm [3] https://github.com/api-platform/admin https://github.com/api-platform/admin

CameronNemo 6y ago
Is wtforms still in use?
- wp381640 6y ago
  using pydantic pretty much everywhere.

tiangolo 6y ago

Ha! You just described 2 of the main future projects I have planned! 1. An admin UI based on OpenAPI, which makes it independent of DB. 2. A mix between Pydantic and SQLAlchemy, to use the same Pydantic model for both (I have some experiment in progress). I just need to find the time for it all, but it's certainly planned.

lukasm 6y ago
> A mix between Pydantic and SQLAlchemy, to use the same Pydantic model for both (I have some experiment in progress). I'm not if it's a good idea. If app is more complex than a TODO you end up with a few way to serialise the same DB model. You have a few schemas to update User in the DB, serlize into the queue without password etc.

uranusjr 6y ago

> I love SQLAlchemy but its syntax is a huge turnoff. Out of curiosity, which part of the syntax? (Hopefully not all of it.) Personally I hate the declarative part (defining the model), but feel the query syntax is good, especially with some SQL knowledge (Django’s isn’t bad either but is too divorced to the SQL syntax to me).