What I love about Django

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.

The only part I don't really agree with, is the avoidance of app separation and signals. It's one of the cleanest ways to decouple your modules and keep some level of sanity in a medium-sized codebase. It comes down to deciding what parts really need to depend on others and be very explicit about that.

I generally end up with a few core apps with the main data objects that a lot of other "parallel" ones depend on, a bit "star shaped". And then a few "aggregator" apps that cover functionality that needs to work across multiple of these domains. I see it all as an extension of how you think about your data model.

Django for Startup Founders: A better software architecture for SaaS startups and consumer apps: https://web.archive.org/web/20210624040717/https://alexkrupp...

This article is very useful.

I use DRF but not serializers and write validations by hand because it is too abstract for me.

My views just call services and return the result.

Nice.

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.

Most loved feature, for me: No dramatic changes, just sane and careful evolution.

Ah the old debate about function-based views and class-based views.

I totally understand why the OP would use only FBV, however when writing REST APIs you will want CBV to reuse base classes such as ListView.

I really like django, but since being involved in it from early days, whenever someone now praises Django, I am reminded of this talk: https://www.youtube.com/watch?v=i6Fr65PFqfk

DjangoCon 2008 Keynote: Cal Henderson

> 3. Actions

It is somewhat explained as a convention or something built-in, but I can't find much about it elsewhere. Is it the author's own convention or am I missing something?

I feel sufficiently old after having read South in this article. Good god what a throwback.

Django is hands down one of my favorite frameworks ever created, and the only one I still reach for in some contexts. For a lot of projects I use it to drive database migrations, and stand up an easy admin portal for others to use - then anything else is driven by an API layer written in (e.g) Rust.

I haven't had to care about Django's performance in years but still get to reap some of the benefits.

What I like about Django are the following things:

(1) It seems whenever I need to adjust how something works, there is some field or method, that I can override, or meta class attribute to set. None of it seems too inflexible. Overriding or changing how things work somehow always feels like someone already thought of this special case I have, and has made it mostly easy to do. Often when I have such a customization case, I have this feeling: "AH, that's how it is supposed to be done in Django." instead of having a feeling of having to fight the framework.

(2) Just being able to use a normal template engine (I always use Jinja2 with Django), instead of having some wannabe HTML lookalike thing. I don't want to have to encode control flow inside HTML attributes. Why then make it look like HTML in the first place, if some JS framework then picks it apart? It is unnecessarily cumbersome to do that, and Django doesn't engage in that.

(3) The ORM is good, and flexible. Some traps for many queries though. But also escape hatches, which let one write ORM calls, that will translate to efficient SQL in most cases.

(4) Django makes it so easy (comparatively) to write a phenomenal searching and ranking function for ones database entities. Check for example the code of my blog [1]. One page of code, very adjustable to ones needs.

(5) Handling of routes is easy. `reverse` is very useful to not have to hardcode routes.

(6) Even when using third-party things like django-allauth it is easy to override templates, without having to modify the dependency itself. With foresight there exists a way to put ones own templates in a place that is discovered before the other package's templates.

(7) Adjustable django admin. I often have some "Tags" in my models, which are many-to-many. For example Posts-TagAssignment-Tag, where TagAssignment is a "throught table". In Django admin one can have a nice little modification [2] to make a very usable widget appear for assigning tags.

In short: It very much gets out of ones way.

[1]: https://codeberg.org/ZelphirKaltstahl/django-website/src/com...

[2]: https://codeberg.org/ZelphirKaltstahl/django-website/src/com...

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.

Since them I'm on Rails.

Migration churn adds up over the years but overall it's nice and site-specific code is usually so small it fits very nice in LLM context.. easy to work with.

I haven’t used Django for a long time but when I did I found it one of the best documented projects out there.

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.

My favourite part of Django is it's not Rails :)

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.