Live data from Hacker News

Some notes on starting to use Django

jvns.ca

141–145 of 145 posts

Re: Some notes on starting to use Django

#141
I've had the misfortune of working in FastAPI a number of times, and, as somebody who has been using Django since 2008, Django developers have no idea how spoiled they are to have such a tremendous framework.

Django does not provide magic, but it's ORM is like pure sorcery compared to the garbage out there (SQLModel, etc.).

Django provides the necessary tools to build terrific software. However, it does not prescribe extra extraordinarily high-level architectural guidance, so it leaves that up to you. For example, if you are building an app that will have a main UI for users to login, a backend UI for managers to view reports, an API for consumption by outside developers, Django doesn't provide some kind of automatic recommended pattern for structuring your app to support all this. However, it provides the exact ingredients you need to do this on your own. In the example a gave, you would simply structure your directories to reflect the various UI / inputs modalities, and then point a path to each section (urls.py). If you want to host your API as a separate service, you just define a WSGI/ASGI app and pointed to a separate urls.py, then start that container using that WSGI/ASGI app, simple as that. Django does not have any kind of magical mono effect structure to it. It is just a collection of unbelievably useful and clean and simple API that you can use to compose software at least 5x more quickly then you can with e.g., FastAPI. I'm in the second team I've been in that is using FastAPI, and it is uncomfortably slow, you wouldn't even believe it. With FastAPI or other API/micro frameworks, I think the perception is that "it's just python" as if Django is something else, and so people start off app.py and they "see now I can start from this fresh canvas", and then they learn after spinning their wheels for two years that having a solid ORM is actually important, having migrations that are always correct and automatically generated is important, having an admin interface for viewing, creating, managing local/testing data while debugging things, etc. is important, having an ORM that lets you do aggregation and annotation so easily that you find yourself wanting to make reports just as an excuse to use these features, is important, having a template system that lets you generate dynamic pages without having to set up a full SPA for every little interface that you want to make allows you to make a quick prototype or even a permanent UI of some kind without having to involve a team of front end developers who will then begin to dictate your entire backend architecture through their litany of ever changing API endpoint requirements. Speaking of, the common pattern that I have noticed with SPA/API based develop is that the front end wants to be large and in charge, until it comes time to validate data inputs or have to do anything with data that requires looking at it holistically (for example, given a list of orders, if there are any orders that have items that are backordered, provide a warning at the top of the page… SPA developers completely crushed by this requirement, now the backend has to add additional information via the end point called "are there backorder items", etc.). So you end up with this hodgepodge of mess, instead of creating a prototype of your interface and then coming back and deciding which things need to be "reactive", and either shoehorning those things in or rewriting your UI because it's absolutely necessary.

This has become quite the rant, but as somebody who has worked on software for nearly 20 years and can hand write HTML, CSS, JavaScript, use Svelte / React, Python, Django, SQL, etc., I've learned a LOT and seen a lot and I can tell you absolute certainty that choosing Django for a new project is the absolute most effective choice you can make on your path to success.

Re: Some notes on starting to use Django

#142
post #132
post #125

Earlier quoted context omitted.

I really want django-seal to be upstreamed, because accidental N+1's are really nasty and django-seal helps a lot with finding those

Isn't that going to be super annoying when doing interactive work or when you really can't avoid it?

django-seal offers optionality on this front. You can choose to use Django's default behavior or opt into sealing for when you're working on code where you _really_ want to avoid N+1's

Re: Some notes on starting to use Django

#143
post #66

Earlier quoted context omitted.

Significantly complex means when ORM starts to become bigger and bigger and you need multiple threads and more complex processes that run in workers. When you start to run into scaling problems, your solution is within that framework and that becomes a limiting factor from my experience. Then as a programmer, you have to find workarounds in Django instead of workarounds with programming. PS: Dealing with a lot of sca…

> Then as a programmer, you have to find workarounds in Django instead of workarounds with programming. The mental unlock here is: Django is only a convention, not strictly enforced. It’s just Python. You can change how it works. See the Instagram playbook. They didn’t reach a point where Django stopped scaling and move away from Django. They started modifying Django because it’s pluggable. As an example, if you’re d…

This sounds like AI?

Re: Some notes on starting to use Django

#144
post #139
post #117

Earlier quoted context omitted.

>If you ever need a CMS in your Django project I strongly recommend Wagtail, it came after the initially most popular django-cms and learned a lot of lessons - feeling much more like a part of Django. Nope. I would choose plain Django 100% of the time, especially with LLMs. Wagtail is an antipattern.

Wagtail is great for what it's good at. If you've ever had to use Django-CMS you'd understand. I went from a Wagtail project to a Django-CMS project (at a company that was upstreaming bits to Django-CMS) and there were so many things where it used the database badly (the usual antipattern of a loop over some queries). It's easy to structure queries in django in an optimised way as long as you architect around .filter…

I don't think I ever said anything about Django-CMS? It may be far worse than Wagtail. Using neither is much better.

Re: Some notes on starting to use Django

#145

I've had the misfortune of working in FastAPI a number of times, and, as somebody who has been using Django since 2008, Django developers have no idea how spoiled they are to have such a tremendous framework. Django does not provide magic, but it's ORM is like pure sorcery compared to the garbage out there (SQLModel, etc.). Django provides the necessary tools to build terrific software. However, it does not prescribe…

Pardon my huge voice-to-text comment ^
Post reply on HN