I really like the ORM and the migrations, but some parts I really dislike. They're maybe not Django's fault, but how it's used most places:
* Models being passed around everywhere, queries happening everywhere. I prefer having a dedicated service/selector layer to do those things. Then convert to pydantic objects or something that's passed around further.
* Corollary, but adding stuff to querymanagers quickly goes out of control. Sure, it's nice to reuse MyModel.objects.annotate_something().annotate_something_else().... but it can quickly become unwieldy and even wrong with exploding joins. And it promotes doing queries in places they shouldn't happen.
* It's veeery easy to make spaghetti. Very easy to query across boundaries, into other apps. Fine on smaller projects, but in huge codebases it quickly makes things hard to control, especially since it's all stringly typed. If I want to modify my model, it's hard to know if someone else have done a query where they did theirmodel__some_relation__another_relation__mymodel__some_field. Blows up in production.
* For some reason it's very common in Django/python projects to have types.py, models.py, selectors.py, views.py, services.py etc. And then each of those end up with lots of unrelated things in the same python file, while related stuff is spread over many files. Django apps doesn't really solve this cleanly either.
I remember, when I used it for the very first time in commercial project. Client briefed me in the afternoon, the next day, before the noon, she got ugly app, but with fully working admin backend. She was sold.
But I also remember, that some non-standard requirements were really difficult to implement or get around.
Having that in mind, the next project was entirely in Pylons. All was good, until we were asked to add Unicode support.
I can take an argument of not buying a Tesla in order to avoid supporting Elons financial empire, but not using Rails because DHH made it is really hard to comprehend.
Django is boring, which is why it works well. Use the ORM together with DRF serializers and an OpenApi generator and you can create TS types and TS client directly from your API.
Works incredibly well almost straight out of the box for even quite large applications. Once you start to grow out of it, it's easy to bypass the ORM and write raw sql queries.
You also won't be re-writing your backend every few years, the cost of which techbros often ignore.
I agree, Django is just fantastic. Nothing is perfect, but Django is just really well-designed, with components that fit together naturally into a balanced whole.
* Models being passed around everywhere, queries happening everywhere. I prefer having a dedicated service/selector layer to do those things. Then convert to pydantic objects or something that's passed around further.
* Corollary, but adding stuff to querymanagers quickly goes out of control. Sure, it's nice to reuse MyModel.objects.annotate_something().annotate_something_else().... but it can quickly become unwieldy and even wrong with exploding joins. And it promotes doing queries in places they shouldn't happen.
* It's veeery easy to make spaghetti. Very easy to query across boundaries, into other apps. Fine on smaller projects, but in huge codebases it quickly makes things hard to control, especially since it's all stringly typed. If I want to modify my model, it's hard to know if someone else have done a query where they did theirmodel__some_relation__another_relation__mymodel__some_field. Blows up in production.
* For some reason it's very common in Django/python projects to have types.py, models.py, selectors.py, views.py, services.py etc. And then each of those end up with lots of unrelated things in the same python file, while related stuff is spread over many files. Django apps doesn't really solve this cleanly either.
But I also remember, that some non-standard requirements were really difficult to implement or get around.
Having that in mind, the next project was entirely in Pylons. All was good, until we were asked to add Unicode support.
Since them I'm on Rails.
I've been meaning to do my own Django post, on some other bits we take for granted - I should do it.
People should be using Django, the best parts are so useful you don't notice them until you switch platforms and implement them badly.
Every app that used a more narrow solution ultimately ends up implementing parts of Django badly.
The best way to solve this from Djangos side would be to have official ways of:
- Using the ORM outside of Django - Doing single file Django apps
Both of these have various 3rd party solutions, which shows demand.
In the past other bits of Django have been split off by 3rd parties but those two are the places to start.
I can take an argument of not buying a Tesla in order to avoid supporting Elons financial empire, but not using Rails because DHH made it is really hard to comprehend.
I don't understand how people can be so out of touch.
Works incredibly well almost straight out of the box for even quite large applications. Once you start to grow out of it, it's easy to bypass the ORM and write raw sql queries.
You also won't be re-writing your backend every few years, the cost of which techbros often ignore.