I don’t get why there is so much negativity on Django when Instagram and other large websites still use it.
I used it a few years ago for a startup and I liked it. It also has a user management system built in also .
I used it a few years ago for a startup and I liked it. It also has a user management system built in also .
> I mean, Instagram server is still a big Python codebase. It's Django at the core, I mean, it still runs through the Django request handling stack, and the middleware and views and URL routing, all of that is still Django. It looks familiar to any Django developer. Just very big, lots of views, lots of URLs, lots of code. There's a lot of, I mean, obviously, the ORM we don't use anymore, the admin is very much based on the ORM, so that's not in use anymore. And there's a lot of components, where Django provides kind of pluggable back ends, like sessions and authentication, and for all of that stuff, we've essentially rewritten the entire system. But we're actually still using the sort of Django API for those things, because it's pluggable. So I would call that a success story, I mean, in that we've been able to very smoothly migrate away from the components that that no longer worked at our scale, in many cases without even having to change the client code touching those subsystems because Django provides this ability to swap out the back end. So yeah, and you know, the Django core requests support that we still use, we're 100% async now, so already a few years ago, we kind of forked and modified a bunch of that to support async, or concurrent handling of multiple requests using async IO. So there have been some changes.
I would say it is a Django success story but given how much has been replaced it sounds more like a Python success story to me.
It’s a reasonable ORM, but doesn’t compare to SQLAlchemy.
A dirty-tracking mode would be great. This is really useful if you want to have code that builds up a list of sub-objects, and then _maybe_ commits them, but maybe rolls back after creating most of the Python objects. The naive Python you want to write is `for i in range(10): foo.bars.add(Bar(i))` which in the Django ORM triggers a DB write for each bar, even if you error out on the 10th Bar.
As you say, another area where the ORM can bite you is the always-on foreign-key-traversal logic. So if you have loaded model foo, then accessing foo.bar will trigger a SQL query under the covers, if you didn't select_related/prefetch_related properly. This is great for simple use-cases and exploratory coding, but can make it very easy to write code with horrendous performance. Naively-coded views often have hundreds of DB lookups and it's hard to track down where these are coming from when the app is complex and especially when you've got _some_ *_related in place, but you're missing a prefetch somewhere.
The request-handling and template rendering is in my mind the weakpoint.