In 2025, how much does it still make sense to go the Django way vs FastAPI ? Looking for well founded opinions. Not controversy.
If you're looking for a mixture of the two, there's Django Ninja: https://django-ninja.dev
Django 5.2 Released
21–25 of 25 posts
Re: Django 5.2 Released
#22In 2025, how much does it still make sense to go the Django way vs FastAPI ? Looking for well founded opinions. Not controversy.
I've been doing this for nigh-on twenty years now, and my rules of thumb:
* If you're building an API, use fastapi+starlette
* If you're building a CRUD app, use Django if:
* You don't expect to need to "hyperscale" in the near future
* You need an admin UI
* Your project resembles a blog or newspaper site (i.e., a collection of articles)
* If you're not using Django, and don't need or want async Python, Flask+SQLAlchemy+alembic is still a 100% valid and effective choice.Re: Django 5.2 Released
#23In 2025, how much does it still make sense to go the Django way vs FastAPI ? Looking for well founded opinions. Not controversy.
It's basically impossible to beat Django's breadth of packages. If you are working with a traditional app, the admin alone can give you 90% of the functionality you'll need.
Use caution here, though.
I've completed a half dozen Django upgrades at this point, and every time I ran into abandoned dependencies. The most difficult of those to deal with were Django extensions - and those were by far the most common I ran into.
In my experience, there are three ways those go:
First, the extension's functionality is no longer necessary (or helpful) because it was rolled into Django, a larger/more popular extension, Django changed enough that there's no longer a need for the extension. This is usually fairly easy to deal with. A few (~1/3?) were even updated to include migration instructions.
Next, the extension was just... abandoned. This usually happens when you have a use case you want the extension to solve, but that use case is so uncommon that there isn't a large enough audience to build a community around the extension. Then the author changes jobs, migrates their codebase, or otherwise just doesn't need to update the extension for their own needs. In this case, you get to decide if you want to remove the functionality from your project, find a replacement extension, or fork the one you're already using. Beware forking projects like this - you're committing to updating for every Django release you upgrade to in the future. I even had one case where I forked an extension only to find that the original author had passed away unexpectedly and there was in fact demand for it. I ended up managing PRs on that one for a couple of years until I was able to find and vet a couple other users to bring on board.
Finally, there are those that are dying a slow death. This could be due to lack of interest, but it seems to usually be because another extension surpassed it in terms of popularity that serves the same function.
The !fun! part is that you can't easily tell which category a dependency is going to fall into until you dig in far enough to find the project's current status. Best case, a quick trip to PyPI and I've got the dependency updated to a newer release in Last time around I ran into a group of dependencies that were all related to our implementation of a GraphQL federated subgraph. That took me a full week to untangle. By the time I was done I'd had to fork and update two libraries, got a PR merged and released on a third, and had to rip out two more. Oh, and because one of those dependencies deprecated and removed support for custom GraphQL backends for serialization, I also had to write a regex-based bash script to transform the result of the default schema generation so it would be compatible with the older version of the GraphQL router that we were using. That was a nasty enough hack that I put an intentional "time bomb" in the script so it would fail loudly if the script hadn't been updated in more than a month - then assigned that alert to the team responsible for the GraphQL router upgrade in the hopes that the (intentional) pain of having to update that file every other sprint would encourage them to prioritize that upgrade, as that service was two years out of date.
Re: Django 5.2 Released
#24In 2025, how much does it still make sense to go the Django way vs FastAPI ? Looking for well founded opinions. Not controversy.
FastAPI isn't an ORM. You use Django for the ORM.
I mostly agree - but not entirely.
Use Django if Django fits your use case. It's really as simple as that. Django is awesome: its features are well-considered, mature, and easy to learn and use. The "batteries included" philosophy means that as long as you're on their happy path, everything will go smoothly and you'll end up saving ridiculous amounts of time.
The problem starts when you try to bend Django to fit your use case, instead of vice-versa. Then all the benefits Django brings to the table turn into things you have to intentionally and carefully work around.
I've used Django ORM without using Django itself several times. It's been a while since I had that particular need, but at one point I'd built out a whole set of in-house ETL pipelines and all their supporting infrastructure using it. Most of that code was in data processing scripts that were only ever called via CLI - but because that company didn't have a ton of Python experience (it was an "enterprise" company circa 2008), and I chose Django ORM because we'd already our people already had experience with it; our reporting system was a Django project. Why require the whole team to pick up another ORM when they already knew one that would work just fine?
I've also used Django without the ORM. I really only wanted a quick web UI that wrapped an existing internal API for a dashboard. I could have used any web framework - or none at all. In fact, the whole thing _could_ have been built in CI and deployed as a static site. I used Django instead because we already had several Django projects in production - so we had documented processes in place to deploy/monitor/manage Django projects, CI templates, and an infrastructure team that we at least knew wouldn't have to get five levels of approval to deploy a "new type of application".
Re: Django 5.2 Released
#25In 2025, how much does it still make sense to go the Django way vs FastAPI ? Looking for well founded opinions. Not controversy.
The admin. I prefer the non Django stuff for everything. Pedantic alembic sqlalchemy and so on.
But if you run something large, getting an admin panel literally for free is difficult to beat. You literally don’t need any admin functionality in your application. Django does it all for virtually free.