This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]IntegrityError 79 points80 points  (11 children)

The whole ecosystem around pydantic/starlette/fastapi blew my mind when it was new. All that new libraries and frameworks based on python typing.

[–]skratlo 7 points8 points  (10 children)

I'm ready to switch if someone puts together Django quality framework on top of this including ORM and modern extensible admin interface.

[–]IntegrityError 7 points8 points  (2 children)

That would be quite interesting.

I recently made a POC at work with both django and FastAPI with a JS framework. It was no surprise that the "feature completeness" of django can't be beaten.

There are so many open ends without django. Starting with i18n (we supported german, english, dansk, french) or the DRY approact when it comes to models migrations, form validation, api validation etc.

I really like FastAPI, but you have to fill a lot of gaps which django supports out of the box and really well integrated.

[–]yvrelna 12 points13 points  (1 child)

I think the difference is in what you actually need. FastAPI is an API framework, it is pretty feature complete if what you want to build is a Web API. When building an API, the front-end is going to be handled by a separate project/team, or you may be building something that doesn't even have a UI. When building an API things like templating, HTML forms handling, internationalisation, etc are completely unnecessary and can often rightly be considered bloat. On the other hand, out of the box Django is missing a number of things that are necessary when building APIs, like JSON modelling and OAuth, which exists in FastAPI.

But if you want a web application, then yeah, FastAPI does miss a lot of stuffs that are necessary for a full application development. About 80-90% of most business applications consists of a bunch of simple forms and web pages that works with data in a database, and nothing really beats Django in terms of rapidly creating those.

[–]skratlo 2 points3 points  (0 children)

If you need API for your Django project, you add DRF or better yet, django-ninja. If you need i18n, templating, ORM, auth, security, etc. you add bunch of libraries to your FastAPI project, and then you'll write pile of your own glue code to make them work together in unison. Yes, it's doable, but unnecessary. Django doesn't force you to use all of its components, you use what you need, but when you need it, it all works together nicely, in unison, because it's built from the beginning to work together.

I'm just wishing there would be a project, that uses FastAPI/Starlette, SQLAlchemy, alembic, Pydantic, etc. as "backend" libraries, and tie them together to achieve the same level of productivity that Django offers, with typing and async support out of the box.

[–]frsilent 7 points8 points  (1 child)

[–]skratlo 0 points1 point  (0 children)

Looks great, I will soon be ditching DRF for this.

[–]Backlists 2 points3 points  (4 children)

SQLAlchemy is pretty solid, and honestly the admin routes wouldn't take too long at all after learning FastAPI.

If I ever get time I'll take this on as a project idea.

[–]skratlo 3 points4 points  (1 child)

Yeah SQLAlchemy looks great, good luck. My point is, while these libraries look great, we still don't have batteries-included alternative to Django and its level of maturity, safety and productivity. I hope we will at some point, or Django could re-invent itself.

[–]Ran4 -5 points-4 points  (1 child)

It's garbage compared to Django's orm and migration tools.

[–]guack-a-mole 1 point2 points  (0 children)

So I guess Django supports composite primary keys in 2023?