They're totally different in terms of the scope of the project they're meant to be used for.

FastAPI is much closer to Flask in that it's trivial to throw up a single file with a couple of routes, and you can use something like SQLite yourself for persistence to disk, or install a couple of libraries for authentication or such (not sure if that's built in by now).

Django, on the other hand, requires a multi-step process to even start a project and creates a dozen of files, most of which are boilerplate, before you can even see a "hello world" route.

But in exchange, you get not just a program which deals with routing and templates and status codes, but much more - a world-class ORM which integrates pretty much transparently with multiple data stores like Postgres or SQLite, an amazing dashboard out of the box which is really handy for sharing with non-techies, a very mature ecosystem, and perhaps most importantly, the "one right way to do things", which makes it a lot more effective for collaboration between a bunch of engineers. It's of course not infallible, has a learning curve, and comes with a good few footguns that get the uninitiated, but the upside is a real upside. Migrations alone might justify it - for all the grief of merge conflicts between migrations right before a code freeze, I can't imagine how much worse it would be to not have them.

So I wouldn't say there's significant advantages to using either - they're different tools for different use cases. If you want to get something up quick that isn't too complex, FastAPI is great for that. If you know you're eventually going to rewrite Django but worse, you may as well use the real thing.

I've just made a first project in fastAPI, and it was trivially simple compared to my previous adventures in DRF. Plus asyc from the get go, which was also pleasant. I had a task as part of this that takes 10 seconds to run, and there's a built in way to allow it to run in the background.

And the documentation is excellent.

> I've just made a first project in fastAPI, and it was trivially simple…

My experience has been, as Seth Godin says, “the long-cut is the most direct route to get to where you seek to go”

Every time I started with Django, I hated the feeling of sitting in boilerplate hell early on.

Every time I started with FastAPI/Flask, I get something working quickly, then hit a wall of recreating everything that comes with Django.

The only solution I’ve found is: embrace boilerplate [1], automate the boilerplate.

[1] Django, or whatever batteries included framework you like (Rails, Laravel, Phoenix, etc)

Yeah, at a past job I had to build out a way to run launchdarkly in FastAPI and it was very unpleasant. Launchdarkly only ships a sync python client so we ended up having to run it in another process to avoid blocking all requests

I found DRF to be great at generating fairly simple APIs very quickly. But complicated stuff gets... more complicated, due to inheritance and magic. I love me some DRF, govscent uses it: https://govscent.org/api/

All from a few lines of code.

But I've mostly switched to django-ninja which is more type safe and faster.