Django 5.0(djangoproject.com)
djangoproject.com
Django 5.0
https://www.djangoproject.com/weblog/2023/dec/04/django-50-released/
236 comments
> 6 years later, the Django side needed minimal changes and is up and running (I jumped all the way from 1.11 to 5.0 beta).
I've been using Django since before 1.0, and the upgrade story has been nothing short of fantastic for something that's been around this long. But still, YMMV!
Depending on how ancient a project you run into, it definitely can be a major pain, even with the original authors' best intentions. For example, Django didn't have its own DB migration system until 1.7 (relying on third party solutions); this means you also have to adjust the deployment procedure, which means recreating an ancient setup (ideally in an easily repeatable fashion, because you're going to be trying that migration at least a dozen times).
The builtin admin system is also a pretty decent CMS on its own, but falls short as you run into slightly more complex use cases (such as basically anything that requires even a single line of JS). The docs will encourage you to copy and override the builtin templates; this often becomes a pain point during upgrades. It's wise to get off the builtin admin system as your project grows.
I've been using Django since before 1.0, and the upgrade story has been nothing short of fantastic for something that's been around this long. But still, YMMV!
Depending on how ancient a project you run into, it definitely can be a major pain, even with the original authors' best intentions. For example, Django didn't have its own DB migration system until 1.7 (relying on third party solutions); this means you also have to adjust the deployment procedure, which means recreating an ancient setup (ideally in an easily repeatable fashion, because you're going to be trying that migration at least a dozen times).
The builtin admin system is also a pretty decent CMS on its own, but falls short as you run into slightly more complex use cases (such as basically anything that requires even a single line of JS). The docs will encourage you to copy and override the builtin templates; this often becomes a pain point during upgrades. It's wise to get off the builtin admin system as your project grows.
FWIW I've also had the same experience; the last version of Django where upgrading took a non-trivial amount of time was 1.8, because it changed how isolation is enforced within test cases. Since then it's rarely taken more than an hour or two, regardless of how big the codebase is.
> The builtin admin system is also a pretty decent CMS on its own (...) It's wise to get off the builtin admin system as your project grows.
And go to another superbly robust and easy to use actual CMS: wagtail.
And go to another superbly robust and easy to use actual CMS: wagtail.
Wagtail is absolutely fantastic for content-heavy websites, like blogs, journals, catalogues, archives, venues (event schedules), also everything that deals with loosely-structured data. It's much less useful as a general purpose CRUD framework - it's too focused on "content", it wouldn't spark joy.
Also it's been a few years since I've last used it, but the overwhelming dominance of deeply nested JSON fields makes ordinary DB migrations unnecessarily interesting.
Also it's been a few years since I've last used it, but the overwhelming dominance of deeply nested JSON fields makes ordinary DB migrations unnecessarily interesting.
> it's too focused on "content".
Isn't that a good thing for a Content Management System?
I am not sure I understand what you think could be done to either the admin (or wagtail) to make them "CRUD frameworks".
Isn't that a good thing for a Content Management System?
I am not sure I understand what you think could be done to either the admin (or wagtail) to make them "CRUD frameworks".
Maybe I'll expand a little bit on the context... Both "CMS" and "CRUD framework" were unfortunate choices of words, and don't quite represent the actual problem.
The Django Admin implements the MVVM pattern; you declare a "ModelAdmin" (aka a ViewModel) subclass, where you can say things like "display the fields in this order" or "run this function to validate that field", and never ever touch any SQL, ORM, HTML, etc until necessary. It is extremely powerful: every line of declarative code saves you hundreds of lines of writing the lower layers; every line you can't write declaratively, can be instead expressed by a mere dozen, using the built-in escape hatches. This pattern of getting "just one layer below" can continue for quite a while, until you suddenly run into an unexpected hard wall.
For example, there is no way to mix the ordering of "fieldsets" and "inlines" (the latter being the only meaningful way to support M:N relations). The community has gathered a couple hacky workarounds (like post-processing the generated template to re-order the sections), but to address the root of the issue would be to merge "fieldsets" and "inlines" into a single property that controls both. So I've embarked on that task, and started hacking on the admin, only to find some of the most gruesome spaghetti entangling the path - I suspect big chunks of that code were hastily thrown together in mid-late 2000s, and barely touched since.
This is a recurring problem - almost every single customer I've talked to is about 95% happy with using the Django admin, but these tiny things that require disproportionate effort keep ruining our day.
Wagtail is not a general solution to this problem; it solves some of the larger pain points (for example, by liberally using JSONFields, which as I've mentioned come with problems of their own), but actually makes editing larger amounts of more structured data a bit more awkward, since it doesn't even come with all of Django admin's (limited) flexibility, and mixing the two in a single project results in an unmitigated UX disaster.
I think I have a pretty good idea of what I'd like to replace Django admin with, unfortunately I've done extensive research and none of the existing alternatives are quite it - you always have to give something up, because the tool is too specialized, makes too many assumptions about your use case. However I think the core principles of Django admin hold very strongly; it's just that the implementation is lacking, and probably will never be addressed, as ease of upgrading will always continue to win (and kudos to Django for that - again, I've been through quite a few legacy projects).
I think there is space for a third-party admin replacement that adheres to this spirit, but breaks all backwards compatibility to clean up the architecture. It would require careful and conservative tech stack choices; I'd like it to survive the next 20 years and allow projects built today to enjoy the same easy path forward. I'd be more than happy to work on that, unfortunately I'm a little preoccupied bending the existing code to my will ;)
The Django Admin implements the MVVM pattern; you declare a "ModelAdmin" (aka a ViewModel) subclass, where you can say things like "display the fields in this order" or "run this function to validate that field", and never ever touch any SQL, ORM, HTML, etc until necessary. It is extremely powerful: every line of declarative code saves you hundreds of lines of writing the lower layers; every line you can't write declaratively, can be instead expressed by a mere dozen, using the built-in escape hatches. This pattern of getting "just one layer below" can continue for quite a while, until you suddenly run into an unexpected hard wall.
For example, there is no way to mix the ordering of "fieldsets" and "inlines" (the latter being the only meaningful way to support M:N relations). The community has gathered a couple hacky workarounds (like post-processing the generated template to re-order the sections), but to address the root of the issue would be to merge "fieldsets" and "inlines" into a single property that controls both. So I've embarked on that task, and started hacking on the admin, only to find some of the most gruesome spaghetti entangling the path - I suspect big chunks of that code were hastily thrown together in mid-late 2000s, and barely touched since.
This is a recurring problem - almost every single customer I've talked to is about 95% happy with using the Django admin, but these tiny things that require disproportionate effort keep ruining our day.
Wagtail is not a general solution to this problem; it solves some of the larger pain points (for example, by liberally using JSONFields, which as I've mentioned come with problems of their own), but actually makes editing larger amounts of more structured data a bit more awkward, since it doesn't even come with all of Django admin's (limited) flexibility, and mixing the two in a single project results in an unmitigated UX disaster.
I think I have a pretty good idea of what I'd like to replace Django admin with, unfortunately I've done extensive research and none of the existing alternatives are quite it - you always have to give something up, because the tool is too specialized, makes too many assumptions about your use case. However I think the core principles of Django admin hold very strongly; it's just that the implementation is lacking, and probably will never be addressed, as ease of upgrading will always continue to win (and kudos to Django for that - again, I've been through quite a few legacy projects).
I think there is space for a third-party admin replacement that adheres to this spirit, but breaks all backwards compatibility to clean up the architecture. It would require careful and conservative tech stack choices; I'd like it to survive the next 20 years and allow projects built today to enjoy the same easy path forward. I'd be more than happy to work on that, unfortunately I'm a little preoccupied bending the existing code to my will ;)
The jump from Django to wagtail was like the jump to Django in the first place, I wish more projects I get to work on were based on it.
<3 South
I'm with you on this, Django + HTMX + Vanilla JS (where needed) just works which is a beautiful thing.
Is building out the UI clunkier with Django templates than with JSX? Absolutely.
But not having to worry about both server and client side state is such a time saver and you know it is going to continue to work.
For the past few years I've been using Go (using Gin) in place of Django, and it works nicely and is quite a bit faster. However, recently I've been toying around with Django again, thinking about making it my default for new projects because it really does take care of so much that you'd otherwise have to deal with yourself.
Is building out the UI clunkier with Django templates than with JSX? Absolutely.
But not having to worry about both server and client side state is such a time saver and you know it is going to continue to work.
For the past few years I've been using Go (using Gin) in place of Django, and it works nicely and is quite a bit faster. However, recently I've been toying around with Django again, thinking about making it my default for new projects because it really does take care of so much that you'd otherwise have to deal with yourself.
An approach I've done in the past for projects that are publicly API-based:
Django handles the database migrations and user accounts/models/etc - and you get the useful admin to boot, which is just incredible if you ever need to open up the data layer to someone else.
Then just write the API interface in Go/Rust/your language of choice. It decouples the DB modeling from the API layer, but in practice... I've just not run into significant issues with it. I'm sure it could be an issue though, so YMMV.
Django handles the database migrations and user accounts/models/etc - and you get the useful admin to boot, which is just incredible if you ever need to open up the data layer to someone else.
Then just write the API interface in Go/Rust/your language of choice. It decouples the DB modeling from the API layer, but in practice... I've just not run into significant issues with it. I'm sure it could be an issue though, so YMMV.
It's not a bad idea, but the tradeoff is usually you'll have to define your models twice. For whatever reason, that tends to happen anyway, so not that big a drawback in practice.
Eh, in my case I prefer writing raw SQL for the API side of things - it's more apparent what's going on in code that I actually tend to wind up debugging down the road. As a result I don't really feel like I'm writing models twice - I model then code, then just read it directly, if that makes sense.
You are ultimately still right, I think - just a personal nuance I guess.
You are ultimately still right, I think - just a personal nuance I guess.
As a full-time Node.js dev, I agree with your decision! Too much time is wasted on compatibility problems. I'd almost say it was easier when we just had browsers to deal with. At least you could just drop in jQuery and call it a day.
Yes, jQuery is often derided as outdated, but it worked quite well for a very long time, with minimal hassle for developers. In fact, I was working full-time on static Elixir/Phoenix pages with jQuery sprinkled on top as late as 2022… it felt a bit clunky but it worked as advertised and wasn’t frustrating in any significant way.
I still use JQuery because of all the syntactic sugar and shortcuts.
Me too, I prefer the API.
At the end of the day I’m delivering reliable and productive solutions for my clients, and they don’t care what the tech is.
However the Django API, GraphQL with React front end stack I’ve inherited is an frustratingly flakey to use and a nightmare to develop :-/
It’s so bad I’m regretting all my life choices that led me to this point LOL
At the end of the day I’m delivering reliable and productive solutions for my clients, and they don’t care what the tech is.
However the Django API, GraphQL with React front end stack I’ve inherited is an frustratingly flakey to use and a nightmare to develop :-/
It’s so bad I’m regretting all my life choices that led me to this point LOL
I’m curious to hear what are some of the most frustrating points developing with Django, React, and GraphQL.
same here, maybe we can improve things!
I mean, a whole sea of WordPress developers still use JQuery. It's still out there and thriving.
I absolutely agree. Recently I had to work on a complex client app, and I could simply not believe the amount of trouble you have to go through when you want to increment the version number of things like React, MUI, webpack, TS by.. one!
> want to increment the version number of things like React, MUI, webpack, TS by.. one!
To be fair, in semver that means a breaking change of some sort.
To be fair, in semver that means a breaking change of some sort.
It does, however it also does for Django.
Breaking changes can vary between 'these one or two things out of thousands must be changed' and 'yeah we did a rewrite and its a new library but we kept the name as its pretty well known'.
Breaking changes can vary between 'these one or two things out of thousands must be changed' and 'yeah we did a rewrite and its a new library but we kept the name as its pretty well known'.
> I’m going to skip the drama and just use htmx for the client-side. Render Django templates server-side, include a single JS script, thrown in some HTML attributes, distinguish between full page requests vs. requests for a partial with updated data, and call it a day.
More of a side comment, but I'm skeptical of the way HTMX encourages partial renders like this. It feels like a premature optimization that adds more complexity on the back end. `hx-select` takes care of it, but to me it feels like it should be the default (it's what Unpoly does).
More of a side comment, but I'm skeptical of the way HTMX encourages partial renders like this. It feels like a premature optimization that adds more complexity on the back end. `hx-select` takes care of it, but to me it feels like it should be the default (it's what Unpoly does).
There is a package, https://github.com/carltongibson/django-template-partials, that is basically like server-side hx-select, when there is some performance concern. Overall, I agree with you though, hx-select is going to be fine most the time.
Thanks for sharing that! I also just finished watching Carlton’s talk from DjangoCon EU (linked in the repo) and it is gold: https://youtu.be/_3oGI4RC52s
There is a header that htmx injects to indicate you want a partial render, and it’s really not that hard to add an if on the server-side to check for it. A larger codebase would probably break templates up anyway for maintainability, so it’s just a tiny amount of extra work if you want to reduce the amount of HTML being sent over the wire and swapped in.
Django and django-unicorn is really nice. It feels like meteorjs but for Django, extremely productive. I've been working with the creator closely and he's awesome.
django-unicorn is really impressive! So glad to see people pushing back on all the gunk inherent in webdev still.
it's neat! Not 1.0 yet but it's coming along. I find it more productive than react etc.
I haven't used Elixir yet and mostly using flask in Python for work but I started with Django (and still think it's better than flask for most apps). If stuff like https://github.com/aesmail/kaffy (first thing I've found on google, never heard of it before) is on par with the Django admin, would you still use Django or Elixir and never look back?
I don’t know if I would “never look back” to Django (I’m a sentimental person). But admin is one aspect, the other big one is auth. I also like DTL better than EEx/HEEx. And all the pieces of Django just fit together really nicely; where Ecto happens to be the preferred way to interact with a database from Elixir, and Phoenix happens to be the preferred way to build Web apps using Elixir, (maybe with Ash layered on top), they weren’t designed by the same people, so you have packages like ecto_phoenix, ash_phoenix, etc. to make them all play together in an elegant way.
I will admit, Elixir and Phoenix have better real-time and scalability stories.
If I had a choice I would probably prefer Elixir/Phoenix/LiveView when joining an org to work on an established codebase that may have actual scalability needs and concerns. But I would probably prefer Django when starting from scratch.
I will admit, Elixir and Phoenix have better real-time and scalability stories.
If I had a choice I would probably prefer Elixir/Phoenix/LiveView when joining an org to work on an established codebase that may have actual scalability needs and concerns. But I would probably prefer Django when starting from scratch.
Totally agree, but is Ember truly the most stable? This is pretty much my only criteria for JS at this point.
If you want a heavyweight JS framework, Ember is the most stable and best supported. I enjoyed Ember when I used it in the 2015-2017 time frame.
But I’m abandoning the heavy JS paradigm in favor of htmx. Aside from the fact that I don’t want to duplicate routing and data validation across client and server, htmx is intentionally a single JS file with no build step, so in theory it should run fine as long as browsers maintain backward compatibility.
But I’m abandoning the heavy JS paradigm in favor of htmx. Aside from the fact that I don’t want to duplicate routing and data validation across client and server, htmx is intentionally a single JS file with no build step, so in theory it should run fine as long as browsers maintain backward compatibility.
Fwiw trying to get an old ember app running was an absolute nightmare. On top of that it is way too heavy for my liking. Pretty much polar opposite of jquery.
i've been using django + htmx and vanilla js where needed. it's great!
my biggest beef with it is code organization, which will only get better with more experience. and it's a side project so it doesn't matter. i do worry about using it on a team because i could this stack getting messy if not done the right way.
my biggest beef with it is code organization, which will only get better with more experience. and it's a side project so it doesn't matter. i do worry about using it on a team because i could this stack getting messy if not done the right way.
Release notes: https://docs.djangoproject.com/en/5.0/releases/5.0/
Related Community Resources
* New goodies in Django 5.0 [blog]: https://fly.io/django-beats/new-goodies-in-django-50/
* What's new in Django 5.0 [video]: https://youtu.be/lPl5Q5gv9G8?feature=shared
* Database generated columns⁽¹⁾: Django & SQLite [blog]: https://www.paulox.net/2023/11/07/database-generated-columns...
* Database generated columns⁽²⁾: Django & PostgreSQL [blog]: https://www.paulox.net/2023/11/24/database-generated-columns...
* Building a Bootstrap styled form in vanilla Django [blog]: https://smithdc.uk/blog/2023/bootstrap_form_in_vanilla_djang...
Related Community Resources
* New goodies in Django 5.0 [blog]: https://fly.io/django-beats/new-goodies-in-django-50/
* What's new in Django 5.0 [video]: https://youtu.be/lPl5Q5gv9G8?feature=shared
* Database generated columns⁽¹⁾: Django & SQLite [blog]: https://www.paulox.net/2023/11/07/database-generated-columns...
* Database generated columns⁽²⁾: Django & PostgreSQL [blog]: https://www.paulox.net/2023/11/24/database-generated-columns...
* Building a Bootstrap styled form in vanilla Django [blog]: https://smithdc.uk/blog/2023/bootstrap_form_in_vanilla_djang...
My app is a Django backend and a Vue frontend. There are large swathes of Django that I ignore, but to me the core of Django — its ORM, routing and middleware system, and admin interface — are worth their weight in gold. The migration from DRF to Django-Ninja (which is, roughly, FastAPI + Django) has also been a great improvement in terms of productivity and performance.
Not a lot of whizbang features in 5.0, but GeneratedField looks like a very nice addition, and reason enough to migrate.
Not a lot of whizbang features in 5.0, but GeneratedField looks like a very nice addition, and reason enough to migrate.
Coming from iOS/macOS background, I've kinda enjoyed Django with its all time classics (forms, templates, etc.) + HTMX.
Admin interface was extremely helpful, when we are trying to validate business idea.
Admin interface was extremely helpful, when we are trying to validate business idea.
Mine too - Vue and django, and the django rest framework, it’s super productive - no writing all the crud views manually for the hundreds of models I have, the django admin interface is very helpful like you say, and backend is running (a very highly customized) django celery mix,
Django + REST framework takes a little more to learn than something like FastAPI, but once you understand how all the middleware, permission and query classes work, you can be hyper productive
Django + REST framework takes a little more to learn than something like FastAPI, but once you understand how all the middleware, permission and query classes work, you can be hyper productive
GeneratedField looks interesting, but I'm not _really_ sure what gains I get over just calling annotate() on my queryset with some computed fields. At least on the backends where the computed GeneratedField isn't stored.
It's easier to re-use if you need the same generated field in multiple places.
I've been in the habit of replacing the default manager for my model with one with an annotated query set. that way, any Model.objects.all() call will have the computed fields.
I find this pretty easy to get used to and re-use. though I do admit I like them defined as actual model-fields with verbose names etc...
I find this pretty easy to get used to and re-use. though I do admit I like them defined as actual model-fields with verbose names etc...
Actually having the derived data in the database would be helpful for simplifying something like a website search implementation. I know I could have used it last month!
It's a generated column in the database, vs. annotate is just a python alias for something you're selecting in the query.
Any resources/examples you'd recommend for a Vue frontend w/django? I've been pretty firmly in backend land for a while and would to experiment with the other half of the puzzle!
I'll preface all of this with a couple esoteric design goals that I had in mind:
1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc.
2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea.
---
With that in mind, some specific packages that I highly recommend:
1. Django-vite (https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model
2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript). This means when I add, say, a new field to a response in Django, I immediately get typechecking for it in Vue — which has been _tremendously_ useful.
3. Django-typescript-routes (a package I extracted and open-sourced!: https://github.com/buttondown-email/django-typescript-routes) which gives your front-end routing information based on the Django router.
1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc.
2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea.
---
With that in mind, some specific packages that I highly recommend:
1. Django-vite (https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model
2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript). This means when I add, say, a new field to a response in Django, I immediately get typechecking for it in Vue — which has been _tremendously_ useful.
3. Django-typescript-routes (a package I extracted and open-sourced!: https://github.com/buttondown-email/django-typescript-routes) which gives your front-end routing information based on the Django router.
If you really need VueJs in the frontend, consider, that you can simple serve the VueJs on any page where it is actually needed. VueJs does not necessarily mean you must create a SPA. VueJs can be delivered like any other script and this is often the easiest way without having to commit to build a full blown SPA.
How was the effort to migrate from DRF to Django-Ninja? I saw Django-Ninja mentioned in another post and am thinking of switching one of my projects over from DRF. After skimming their documentation, it looks very pleasant and simple and perfect for my use case.
Going from 0 → 1 migrated route was "medium difficulty", I'd say — there was a non-trivial amount of scaffolding I had to build out around auth, error codes, and so on, and django-ninja's docs are still a little lackluster when it comes to edge cases.
Once I had that one migrated route, though, the rest were very simple. (And I am very happy with the migration overall!)
Once I had that one migrated route, though, the rest were very simple. (And I am very happy with the migration overall!)
I've had that on my list to try out for a while now. FastAPI is a joy, having generated OpenAPI is a must, so Ninja sounds good.
I've had quite enough of DRF's tower of mixins and rails like magic. It always sucks up development time and fails too easily.
I've had quite enough of DRF's tower of mixins and rails like magic. It always sucks up development time and fails too easily.
Agreed, the admin makes development so much easier, being able to easily enter and view your data.
Sadly I don't use Django anymore at work but it still has a special place in my heart. The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong.
In recent years Django had multiple major releases, I still remember it as being in 1.x forever. Does somebody know what changed within the Django Community that they break backward compatibility more often?
In recent years Django had multiple major releases, I still remember it as being in 1.x forever. Does somebody know what changed within the Django Community that they break backward compatibility more often?
The release process is time-based as to roughly every 8 months[1] with X.0, X.1, and X.2 (LTS). This is mostly to communicate which release has long term support.
The deprecation policy[2] is taken very seriously and Django doesn't opt to break things if it can.
Recently there was a very interesting discussion[3] between the Fellows as to whether the version numbering is confusing as this doesn't follow the same pattern as other libraries.
1: https://docs.djangoproject.com/en/dev/internals/release-proc...
2: https://docs.djangoproject.com/en/dev/internals/release-proc...
3: https://fosstodon.org/@carlton/111300877531721385
The deprecation policy[2] is taken very seriously and Django doesn't opt to break things if it can.
Recently there was a very interesting discussion[3] between the Fellows as to whether the version numbering is confusing as this doesn't follow the same pattern as other libraries.
1: https://docs.djangoproject.com/en/dev/internals/release-proc...
2: https://docs.djangoproject.com/en/dev/internals/release-proc...
3: https://fosstodon.org/@carlton/111300877531721385
> The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong.
Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...
Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...
Simple middleware can warn you about lazy loading/N+1 queries. Most of the time people just forget it happens.
Try using: https://github.com/har777/pellet
Disclaimer: I built it :p
You can easily see N+1 queries on the console itself or write a callback function to track such issues on your monitoring stack of choice on production.
Try using: https://github.com/har777/pellet
Disclaimer: I built it :p
You can easily see N+1 queries on the console itself or write a callback function to track such issues on your monitoring stack of choice on production.
I did this by adding every SQL query to a new log file (only active in development), then tailing it while developing. Not only is 1+N very visible as a long string of the same query over and over, it also lets you see in real time when there's a long pause from a query taking longer than expected.
Also we often had something that was more like 1+3N, basically a 1+N problem but it was looping through the same 3 queries over and over.
Also we often had something that was more like 1+3N, basically a 1+N problem but it was looping through the same 3 queries over and over.
That looks handy, thanks for sharing! I used to use some other n+1 logger, but yours actual shows the query which is more useful.
FWIW Sentry has recently (within the last year or so) rolled out support for N+1 monitoring as well.
Have a pitch on what differentiates this from django-toolbar? Just the focus on query count monitoring?
Yeah the query count monitoring is the main focus as N+1 queries are super common in Django.
I don't really have a pitch but here is why this was made:
1. we had a production DRF app with ~1000 endpoints but the react app consuming it was dead slow because the api's had slowed down massively.
2. we knew N+1 was a big problem but the codebase was large and we didn't even know where to start.
3. we enabled this middleware on production and added a small callback function to write endpoint=>query_count, endpoint=>query_time metrics to datadog.
4. once this was done it was quite trivial to find the hot endpoints sorted by num of queries and total time spent on queries.
5. pick the most hot endpoint with large number of queries, enable debug mode locally, fix N+1 code, add assertNumQueries assertions to integration tests to make sure this doesn't happen again and push to prod.
6. monitor production metrics dashboard just to double check.
7. rinse and repeat.
For me this ability to continuously run on prod -> find issues and send to your monitoring stack -> alert -> fix locally workflow is the main selling point. Or of course you can just have it running locally on debug mode and check your console before pushing your changes but sometimes its just hard to expect that from every single engineer at your company. Then again your local data might not cause an issue so production N+1 monitoring is always nice.
I don't really have a pitch but here is why this was made:
1. we had a production DRF app with ~1000 endpoints but the react app consuming it was dead slow because the api's had slowed down massively.
2. we knew N+1 was a big problem but the codebase was large and we didn't even know where to start.
3. we enabled this middleware on production and added a small callback function to write endpoint=>query_count, endpoint=>query_time metrics to datadog.
4. once this was done it was quite trivial to find the hot endpoints sorted by num of queries and total time spent on queries.
5. pick the most hot endpoint with large number of queries, enable debug mode locally, fix N+1 code, add assertNumQueries assertions to integration tests to make sure this doesn't happen again and push to prod.
6. monitor production metrics dashboard just to double check.
7. rinse and repeat.
For me this ability to continuously run on prod -> find issues and send to your monitoring stack -> alert -> fix locally workflow is the main selling point. Or of course you can just have it running locally on debug mode and check your console before pushing your changes but sometimes its just hard to expect that from every single engineer at your company. Then again your local data might not cause an issue so production N+1 monitoring is always nice.
Monitoring production is the piece I was missing. Was thinking of it as strictly for development.
Unless it adds a bunch of overhead, seems like a no-brainer to enable.
Unless it adds a bunch of overhead, seems like a no-brainer to enable.
It only adds like ~5ms. Unless you have `query_level_metrics_enabled` as True which takes more time. I didn't find that particularly useful on prod and instead just used it locally when fixing stuff. Depends on what data you need populated in your callback function on prod.
The header feature can also be useful. If you have a client on-call who's complaining about super slow page loads. Just check their network tab and see which response has a query count/time header which seems unnatural.
The header feature can also be useful. If you have a client on-call who's complaining about super slow page loads. Just check their network tab and see which response has a query count/time header which seems unnatural.
I think Django's ORM is a product of its time, when limitations about the expressibility of the "active record" concept were not fully understood.
I like to describe it as Django's ORM will satisfy 80% of your needs immediately, 90% if you invest and sweat, 95% if you're quite knowledgeable in the underlying SQL. But there are still some rather common query shapes that are inexpressible or terribly awkward with Django's ORM.
SQLAlchemy on the other hand never tries to hide its complexity (although to be fair they've become much better at communicating it in 2.0). On Day 1 you'll know maybe 20% of what you need to. You might not even have a working application until the end of week 1. But at the end of, idk, month 6? You're a wizard.
The long-term value ceiling of SQLAlchemy/Alembic is higher than Django's, but Django compensates for it with their comparatively richer plugin ecosystem, so it's not so easy to compare the two.
I like to describe it as Django's ORM will satisfy 80% of your needs immediately, 90% if you invest and sweat, 95% if you're quite knowledgeable in the underlying SQL. But there are still some rather common query shapes that are inexpressible or terribly awkward with Django's ORM.
SQLAlchemy on the other hand never tries to hide its complexity (although to be fair they've become much better at communicating it in 2.0). On Day 1 you'll know maybe 20% of what you need to. You might not even have a working application until the end of week 1. But at the end of, idk, month 6? You're a wizard.
The long-term value ceiling of SQLAlchemy/Alembic is higher than Django's, but Django compensates for it with their comparatively richer plugin ecosystem, so it's not so easy to compare the two.
Non-performant code is going to eventually slip into any codebase. The trick is to monitor for when performance falls to an unacceptable level. Not toss all ORMs because some minority of generated queries are problematic.
If maximum performance, 100% of the time was the end-goal, I would not be writing Python.
If maximum performance, 100% of the time was the end-goal, I would not be writing Python.
The python team I joined grew their codebase from a thin data access layer into a full blown application. Staff was full of data guys and had no idea about application engineering, but lots of opinions. The client was another company who intended the product as heart of their digital transformation.
Guess who had to refactor this mess and steer away from catastrophy.
I’m haunted to this day.
Guess who had to refactor this mess and steer away from catastrophy.
I’m haunted to this day.
That general story can happen with any tech stack.
POC whipped together without good architecture. Having proven itself, usage increases until the application starts to burst at the seams. Program must be redesigned, avoiding performance gotchas.
I still think Django + the ORM give you a lot of runway before performance should be a concern.
POC whipped together without good architecture. Having proven itself, usage increases until the application starts to burst at the seams. Program must be redesigned, avoiding performance gotchas.
I still think Django + the ORM give you a lot of runway before performance should be a concern.
Idk. The python stack strikes as particularly troublesome if you don’t know exactly what you’re doing. There are no guardrails for less experienced devs that prevents you from making basic mistakes.
I also realized mid project that the default rest framework doesn’t support good api model generation from OpenApi or vice versa. And most devs didn’t understand why using untyped dicts everywhere was bad.
In all transparency, I am openly biased for static typing and have a background in java, c# and Swift.
So what we ended up with looked similar to a statically typed language but without the tooling or performance.
I also realized mid project that the default rest framework doesn’t support good api model generation from OpenApi or vice versa. And most devs didn’t understand why using untyped dicts everywhere was bad.
In all transparency, I am openly biased for static typing and have a background in java, c# and Swift.
So what we ended up with looked similar to a statically typed language but without the tooling or performance.
I agree. Combined with a few good habits like favouring select_related() - it's never been a problem.
> Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...
FWIW they do give you assertNumQueries in the testing tools, which makes it relatively easy to catch this as long as you have tests.
FWIW they do give you assertNumQueries in the testing tools, which makes it relatively easy to catch this as long as you have tests.
I sort of said this elsewhere. Others are saying "that's just what happens" and "well, Python?" but it doesn't just happen, and slow database queries are nothing to do with the application language. The problem is Django ORM, like Ruby on Rails, uses the Active Record pattern. Alternate ORMs, such as SQLAlchemy or Hibernate, uses Data Mapper pattern, which avoids the pitfalls of Active Record.
We can have 1+N queries in any language even without an ORM. Maybe an ORM facilitates mistakes because it hides joins but lack of experience is lack of experience. Some naive bad pseudocode:
for book in select * from books:
author = select * from authors
where id == book.id
print book.title author.name
I'm not criticising ORMs, just how active record works.
Well it's trivial in ActiveRecord to avoid n+1s by preloading associations. As with any technology, if you use it wrong and inefficently then things will be incorrect and slow.
Here's an example I remember: if I want to update a field in a million records in my database, I can't just send the update command to the database to run. Instead, an ActiveRecord ORM will try and load all the records into the application, and for each record object make the change in memory, and then persist the record.
If I'm remembering correctly, that is a fundamentally poor approach. Instead of telling the database to do some work, the database is doing more work, and the application is doing work. One mitigation is to batch the work[0]. Another is to special-case updates[1], which bypasses all the ActiveRecord pre/post-save logic. In either case you aren't holding the tool wrong. The tool is wrong.
[0] https://apidock.com/rails/ActiveRecord/Batches/find_each - you'll note that the batches are "subject to race conditions" - i.e. each batch is its own transaction! And you're still loading the records into your application pointlessly. You're just limiting how many do it at once.
[1] https://docs.djangoproject.com/en/dev/topics/db/queries/#upd... - note:
> Be aware that the update() method is converted directly to an SQL statement. It is a bulk operation for direct updates. It doesn’t run any save() methods on your models, or emit the pre_save or post_save signals (which are a consequence of calling save()), or honor the auto_now field option. If you want to save every item in a QuerySet and make sure that the save() method is called on each instance, you don’t need any special function to handle that. Loop over them and call save()
If I'm remembering correctly, that is a fundamentally poor approach. Instead of telling the database to do some work, the database is doing more work, and the application is doing work. One mitigation is to batch the work[0]. Another is to special-case updates[1], which bypasses all the ActiveRecord pre/post-save logic. In either case you aren't holding the tool wrong. The tool is wrong.
[0] https://apidock.com/rails/ActiveRecord/Batches/find_each - you'll note that the batches are "subject to race conditions" - i.e. each batch is its own transaction! And you're still loading the records into your application pointlessly. You're just limiting how many do it at once.
[1] https://docs.djangoproject.com/en/dev/topics/db/queries/#upd... - note:
> Be aware that the update() method is converted directly to an SQL statement. It is a bulk operation for direct updates. It doesn’t run any save() methods on your models, or emit the pre_save or post_save signals (which are a consequence of calling save()), or honor the auto_now field option. If you want to save every item in a QuerySet and make sure that the save() method is called on each instance, you don’t need any special function to handle that. Loop over them and call save()
There does seem to be a natural conflict between large data with hierarchical structure and the generally flat lists and dictionaries of Python, that quickly leads to poor performance. It usually only takes a few foreign keys to create an exponential number of queries.
But I have no idea if there are database interfaces that make this problem simplistic. In my experience with Django, anything but the most simplistic page will be so noticeable slow that one has to go through the queries and use things like select related. Occasionally it is also better to just grab everything into memory and do operations in Python, rather than force the data manipulation to be done as a single database query.
It is a good tool for its purpose, but it is no replacement for SQL knowledge when working with complex relational databases.
But I have no idea if there are database interfaces that make this problem simplistic. In my experience with Django, anything but the most simplistic page will be so noticeable slow that one has to go through the queries and use things like select related. Occasionally it is also better to just grab everything into memory and do operations in Python, rather than force the data manipulation to be done as a single database query.
It is a good tool for its purpose, but it is no replacement for SQL knowledge when working with complex relational databases.
Yes you do have to work on your queries to keep them fast with growing complexity. Django also has a usable intermediate API to construct your queries, instead of writing raw SQL. Nice feature to have if you don't want to commit to a specific database yet.
And as already written above, a slow but correct page is preferable to a wrong page because you ORM is omitting related data.
And as already written above, a slow but correct page is preferable to a wrong page because you ORM is omitting related data.
ORM's always abstract away details, but you monitor for slow queries and slow endpoints and then just fix the issues when they crop up.
I'd rather have a slow page because of lazy loading, than a wrong page because the related objects are not loaded (i.e. typeorm)
lol been refactoring something like this
The ORM is OK as long as you refrain from using any inheritance. If you do, the database becomes a mess quickly and only that very Django app will be able to read and write to it (including manage.py shell). Anything else, other apps in any language or a SQL client, will be lost in a sea of tables and joins.
I've got a customer with two Django apps. One was developed enthusiastically in the object orientation way. The database is a nightmare. The other one was developed thinking table by table and creating models that mimic the tables we want to have. That's a database we can also deal with from other apps and tools.
I've got a customer with two Django apps. One was developed enthusiastically in the object orientation way. The database is a nightmare. The other one was developed thinking table by table and creating models that mimic the tables we want to have. That's a database we can also deal with from other apps and tools.
I've found inheritance to be a problem with pretty much any ORM I've used extensively (Django, Hibernate, NHibernate, Entity Framework). It helps to design your OOP model with that in mind; having no more than one level of inheritance, and using inheritance only to supplement a set of common records seem to be good enough rules of thumb.
tbh, any OOP paradigms used with db tables will end up in a clusterf*ck.
Have you worked with ActiveRecord or Ecto? Just wondering for framing your comment
Not who you’re asking, but I’ve used all 3. I think in terms of query interface you can’t go wrong with any of them. In fact, I like Ecto the most because of its separation between the concept of a “Query” (super flexible and composable) vs. a “Repo” (the module where you call an actual database operation). This helps you avoid hitting the database until you’re sure you want to.
Where Django’s ORM shines is in the modeling stage: classes in models.py are your single source of truth, relationships only need to be defined once, no separate “schema” file, and most of the time migrations can be generated automatically. It’s truly top-notch.
Where Django’s ORM shines is in the modeling stage: classes in models.py are your single source of truth, relationships only need to be defined once, no separate “schema” file, and most of the time migrations can be generated automatically. It’s truly top-notch.
I think SQLAlchemy is better, personally. Still just model files, but it's data mapper pattern means you won't be hitting all the issues people do with active record.
I briefly used Ecto when trying out Phoenix framework but have not worked enough with it to form an opinion.
They switched their versioning scheme after the 1.x.
https://docs.djangoproject.com/en/dev/internals/release-proc...
https://docs.djangoproject.com/en/dev/internals/release-proc...
Similar to bitcoin, they changed to a time-based versioning scheme. Major releases don't indicated that they DID break compatibility, but that they MIGHT HAVE, and more importantly prior versions are no longer supported. Effectively the same as a LTS release.
Django is such a lovely framework I can't speak higher praises of it. I'm blessed to still be able to use it in my day to day work. It's maybe not the most flashy framework out there these days but Django and Rails are really the Toyota Corollas and Honda Civics of the web dev world that often go so underappreciated for their unfussy reliability. :)
I’d say they’re the Lexuses of the web dev world. Very nicely appointed and rock-solid, just not very sexy.
3 years ago I moved to fast growing startup that was founded with fast api slap-dashed together. I jammed Django down their throats and I can safely say it was the best decision we made as an Org. The teams using Django are far far more productive than the others.
When a product I think is going to need users and roles and permissions, I grab Django off the shelf and never look back.
Thank you mister reinhardt
When a product I think is going to need users and roles and permissions, I grab Django off the shelf and never look back.
Thank you mister reinhardt
I am trying to show the value of it in my company: fastapi + vue.js and severy short staffed.
There are so much structural mistakes in our codebase, they use async python but messed it up in all the important places yet believe that Django is slow or innadequate.
They belive that Django is too "old school" and that if you want good results you need vue.js an api and all that.
Truth is, no one has the time and experience to make something good with that.
Developpement is very slow and code is buggy management is unsatisfied with the results yet they refuse to try it out.
It seem their ideas are made up and won't change.
There are so much structural mistakes in our codebase, they use async python but messed it up in all the important places yet believe that Django is slow or innadequate.
They belive that Django is too "old school" and that if you want good results you need vue.js an api and all that.
Truth is, no one has the time and experience to make something good with that.
Developpement is very slow and code is buggy management is unsatisfied with the results yet they refuse to try it out.
It seem their ideas are made up and won't change.
Fwiw, it was an investment while short staffed that paid dividends later on.
It sounds like in your case, like mine, it’s a cultural issue that you are trying to solve, not a technical one. A cultural issue of wanting to deploy and ship a product fast and not worry about the stuff that’s already been solved.
You can always do a POC and show the value of it to the stakeholders. What I did was picked a product that would greatly benefit from it and went through the entire migration process with product and got their buy in.
It sounds like in your case, like mine, it’s a cultural issue that you are trying to solve, not a technical one. A cultural issue of wanting to deploy and ship a product fast and not worry about the stuff that’s already been solved.
You can always do a POC and show the value of it to the stakeholders. What I did was picked a product that would greatly benefit from it and went through the entire migration process with product and got their buy in.
Yeah this is definitely Django's strength - it has a lot of the stuff you're probably going to need already implemented. Massive time saver when you're setting things up.
Python definitely holds it back though. Does it have type hints yet?
Python definitely holds it back though. Does it have type hints yet?
Why do you say python holds it back?
The three big problems with Python:
* It's slow. 'nuff said. No the fact that Numpy exists doesn't change that.
* Lack of static types. I mean, they do exist now which is fantastic, but there are still far far far too many projects not using them. And lots of code that can't be statically typed (e.g. lxml).
* The infrastructure and module systems are a total mess. Literally nobody understands Python imports.
There's also the fact that Python code is generally lower quality than in other languages (except maybe JS) because it's so popular with beginners.
* It's slow. 'nuff said. No the fact that Numpy exists doesn't change that.
* Lack of static types. I mean, they do exist now which is fantastic, but there are still far far far too many projects not using them. And lots of code that can't be statically typed (e.g. lxml).
* The infrastructure and module systems are a total mess. Literally nobody understands Python imports.
There's also the fact that Python code is generally lower quality than in other languages (except maybe JS) because it's so popular with beginners.
What is slow about python? I can onboard and have someone developing python code in our code base in <1 day because of its simplicity. I’m not sure I would call that slow…
Congrats on the release to the Django community!
If anyone is curious, I updated my Django / Docker starter app to use Django 5.0 at: https://github.com/nickjj/docker-django-example
It pulls together gunicorn, Celery, Redis, Postgres, esbuild and Tailwind with Docker Compose. It's set up to run in both development and production.
If anyone is curious, I updated my Django / Docker starter app to use Django 5.0 at: https://github.com/nickjj/docker-django-example
It pulls together gunicorn, Celery, Redis, Postgres, esbuild and Tailwind with Docker Compose. It's set up to run in both development and production.
where do you tend to run stuff in production?
and if you were a startup - any preferences?
It depends.
I personally use DigitalOcean but now that Hetzner is starting to get US data centers that is looking like a good option too.
With no other context, if I were creating a startup today I'd likely go with DigitalOcean.
AWS is also another option, especially if you think you'll be using some of their services.
But for a typical web app + SQL database + cache + object storage set up DO works nicely, although I would still use S3 for object storage even though DO has it, I find S3 to be more dependable.
I personally use DigitalOcean but now that Hetzner is starting to get US data centers that is looking like a good option too.
With no other context, if I were creating a startup today I'd likely go with DigitalOcean.
AWS is also another option, especially if you think you'll be using some of their services.
But for a typical web app + SQL database + cache + object storage set up DO works nicely, although I would still use S3 for object storage even though DO has it, I find S3 to be more dependable.
nice... thanks!
IMHO... Django hold a high standard in terms for projects running beyond the infamous 5+ years of support... still have some projects that with minimal changes (mostly configs and dependencies that got redundant/integrated into django -like choices-) are working with the latest version, surely 5.0 will not be that drastic if you are already doing software "the django way".
Things that are Django achilles heel are not developing software "the django way", mostly anything that needs some client-side to work is a PITA, requires lots of rewriting and custom templates that at some point you gotta start looking django as a backend more like the full stack framework that was meant to be. Also anything related onto getting things to production is another PITA that hasn't been solved or touched in years, dx deployment is one of those things almost any JS Framework out there is doing things better than what django supports.
Things that are Django achilles heel are not developing software "the django way", mostly anything that needs some client-side to work is a PITA, requires lots of rewriting and custom templates that at some point you gotta start looking django as a backend more like the full stack framework that was meant to be. Also anything related onto getting things to production is another PITA that hasn't been solved or touched in years, dx deployment is one of those things almost any JS Framework out there is doing things better than what django supports.
Isn't Developer DX mostly a way to get developers locked into your platform? I have avoided Next.js for this reason, it seems like just a way to funnel developers towards Vercel. DX is largely a service specific problem since its coupled to the service you are deploying to.
I can’t tell if it’s Django or just how I use it—-I’m a mechanical engineer by training and only dabble on web dev—-but I deeply appreciate how it gives me enough abstraction to get going but doesn’t get too far ahead of itself. If I go away for a year or two then come back I still get what’s going on. Meanwhile anything I try on JS land has gone through a few half-lives.
If you want a similar experience in JS check out Joystick [1]. It's being built to mimic the indefinitely stable design of stuff like Django and Rails.
[1] https://github.com/cheatcode/joystick
[1] https://github.com/cheatcode/joystick
Which is just yet another js framework which might disappear next month.
That's the problem.
That's the problem.
You have no reason to believe me but short of my own death halting development, no. I'm not doing it for fashion/clout/money/boredom. I'm doing it because I refuse to work with the mental illness that the JavaScript ecosystem has become.
I've been using Django as my main choice for web projects for over ten years. The reason I like it so much is because it comes with a lot of built-in features that one needs to ship web projects to production. For example, I was first attracted to Django because of its admin interface and its straightforward views and templating system.
Over the years, Django has kept up with changes in web development. An example of this is when database migrations, which used to be a separate project, were integrated into Django itself. The Django community is also strong with great ecosystem projects like DRF for APIs, Django Channels for real-time features, and social-auth for social sign-ins.
My recent use of Django is in (https://github.com/trypromptly/LLMStack). We use Django Channels for WebSocket support, DRF for APIs, and ReactJS for the frontend.
Over the years, Django has kept up with changes in web development. An example of this is when database migrations, which used to be a separate project, were integrated into Django itself. The Django community is also strong with great ecosystem projects like DRF for APIs, Django Channels for real-time features, and social-auth for social sign-ins.
My recent use of Django is in (https://github.com/trypromptly/LLMStack). We use Django Channels for WebSocket support, DRF for APIs, and ReactJS for the frontend.
What's the preferred Python Web Framework these days?
I've read a lot of love for Litestar (formerly Starlite), since it seems people prefer it over FastAPI, Flask, etc.
https://litestar.dev
Or is the preferred web framework still Django?
I've read a lot of love for Litestar (formerly Starlite), since it seems people prefer it over FastAPI, Flask, etc.
https://litestar.dev
Or is the preferred web framework still Django?
I've always felt, and this hasn't changed recently, that if you're going to need more than, say, 3 of the cross cutting concerns that Django provides for, then it'll be much more maintainable in the long run to just use Django rather than effectively building a custom solution out of parts. The flip side: if you're building a small internal API that only needs a couple of these, Django might be overkill.
What do I mean by "cross cutting concerns"? I'm thinking about ORM/models, migrations, admin UI, caching, sessions, misc security middleware, user accounts, validation/forms, templating, RSS feeds, logging, testing infrastructure, etc. Django's pieces all fit together well, and any time I've done this with Flask/etc I've found myself spending so much time solving issues gluing these bits together and working around impedance mismatches between libraries.
We had a large Django site at my last place and would just suggest new starters worked through the Django tutorial, because our site basically still worked like that.
What do I mean by "cross cutting concerns"? I'm thinking about ORM/models, migrations, admin UI, caching, sessions, misc security middleware, user accounts, validation/forms, templating, RSS feeds, logging, testing infrastructure, etc. Django's pieces all fit together well, and any time I've done this with Flask/etc I've found myself spending so much time solving issues gluing these bits together and working around impedance mismatches between libraries.
We had a large Django site at my last place and would just suggest new starters worked through the Django tutorial, because our site basically still worked like that.
I half-agree with you, I've found that there are two options when choosing a framework:
1. You're making something with 100 lines, which you're absolutely sure will stay 100 lines. Go with Flask.
2. Otherwise, Django.
Django is great at getting out of your way when you don't need its functionality, so you can just ignore most of it if you don't need it.
1. You're making something with 100 lines, which you're absolutely sure will stay 100 lines. Go with Flask.
2. Otherwise, Django.
Django is great at getting out of your way when you don't need its functionality, so you can just ignore most of it if you don't need it.
Second this, if you need a database and users, Django is better than the headache of thinking about this yourself with all security pitfalls. I've built several production APIs around Django (like, not CMS at all) and I find it a good compromise between an SDK and rolling your own, this is partly due to Python as well of course.
And I've done smaller things with Flask where it would make no sense to go with Django as well but those were things not really built around a db or CRUD API etc.
And I've done smaller things with Flask where it would make no sense to go with Django as well but those were things not really built around a db or CRUD API etc.
I agree. I would even go so far as to say that if you need an ORM, go with Django. I've wasted too much time adding SQLAlchemy to Flask to get something that is still worse than the Django ORM.
Perhaps, but it depends what you're building. SQLAlchemy is much more capable, so if you need great database control and don't need all the other bits Django is bringing, then I kinda get it.
+1 to that. Maybe SQLAlchemy is a better product, but being a bolted on solution makes everything about the ORM experience feel worse than using Django. If nothing else, it is not just using Flask+SQLAlchemy, now it is Flask+SQLAlchemy+Alembic. Or maybe, you want the niceties, so it is Flask+SQLAlchemy+Alembic+FlaskMigrate.
Exactly. It's the migration support that I find the best feature of Django, but I keep forgetting about it until I have to migrate with some other ORM.
They way I'd look at it - if your app owns the database and schema, use Django. If your app is connecting into someone else's database or databases (like in enterprises with DBA priesthoods etc), the flexibility of SQLAlchemy can fit better around arbitrary schemas etc.
Depends what you're solving for. Building a website that requires user authentication and basic relational DB... I default to Django. But if I'm building small internal services then I go FastAPI or Flask. Django's ORM is still dreamy.
I used to like DRF (Django Rest Framework) and Django + DRF was a powerful combo to drive single-page-application sites. But DRF can get a little painful if you're not using some of the out-of-the-box classes. Painful as in... lots of code to right and very hard for someone to maintain without knowledge of how DRF magic is made under the hood.
I used to like DRF (Django Rest Framework) and Django + DRF was a powerful combo to drive single-page-application sites. But DRF can get a little painful if you're not using some of the out-of-the-box classes. Painful as in... lots of code to right and very hard for someone to maintain without knowledge of how DRF magic is made under the hood.
I choose between Django and Litestar these days.
I wish I had a hard and fast rule for the choice, but it's something like:
- Litestar if I know with certainty (a) the thing I'm building is and always will be a tiny service and (b) I probably won't have to evolve the backing data schema much. Wrap an ML model? Litestar. Have a small database I want to expose via API, read-mostly? Litestar.
- Django if I know (a) I'm going to be building on this over a longer timeframe, (b) I have complex user/group auth needs, (c) my data schema will likely go through substantial evolution, or (d) I will need an admin UI in the early goings, either for the managing team or for customer support.
I have plenty of SQLAlchemy+Alembic+Litestar backends but I vastly prefer the creature comforts of Django's ORM + migrations; it hits that 80% sweet spot so very well. SQLalchemy is both raw power and, often, far too much friction.
I used to choose between Django and Flask, but Litestar -- while still young -- seems to capture most of the key things I liked about core Flask but in a more modern package. (Maybe Quart, aka async Flask, will ultimately win the day; not sure.)
It's not targeted at the use case, but I wonder if Datasette will replace my need for the Django admin UI at least in some limited set of cases.
These days, most of my front-ends are React+Typescript+Vite.
(FWIW I personally avoid FastAPI entirely. I appreciate the impact it had getting the python community to think about (a) async (b) proper use of type hints in the web context and (c) the need for OpenAPI support, etc. but there are a lot of footguns and so many issues still opened that its (amazing, lovely) single maintainer probably won't get to. SQLModel -- aka the merging of Pydantic + SQLAlchemy ORM models -- is an even bigger trap, IMO.)
I wish I had a hard and fast rule for the choice, but it's something like:
- Litestar if I know with certainty (a) the thing I'm building is and always will be a tiny service and (b) I probably won't have to evolve the backing data schema much. Wrap an ML model? Litestar. Have a small database I want to expose via API, read-mostly? Litestar.
- Django if I know (a) I'm going to be building on this over a longer timeframe, (b) I have complex user/group auth needs, (c) my data schema will likely go through substantial evolution, or (d) I will need an admin UI in the early goings, either for the managing team or for customer support.
I have plenty of SQLAlchemy+Alembic+Litestar backends but I vastly prefer the creature comforts of Django's ORM + migrations; it hits that 80% sweet spot so very well. SQLalchemy is both raw power and, often, far too much friction.
I used to choose between Django and Flask, but Litestar -- while still young -- seems to capture most of the key things I liked about core Flask but in a more modern package. (Maybe Quart, aka async Flask, will ultimately win the day; not sure.)
It's not targeted at the use case, but I wonder if Datasette will replace my need for the Django admin UI at least in some limited set of cases.
These days, most of my front-ends are React+Typescript+Vite.
(FWIW I personally avoid FastAPI entirely. I appreciate the impact it had getting the python community to think about (a) async (b) proper use of type hints in the web context and (c) the need for OpenAPI support, etc. but there are a lot of footguns and so many issues still opened that its (amazing, lovely) single maintainer probably won't get to. SQLModel -- aka the merging of Pydantic + SQLAlchemy ORM models -- is an even bigger trap, IMO.)
I know it's not "shiny and new" but Django is still serving us very well were I work.
The only two things it lacks great support of is typing and async. However the async is actively being worked on and does work (with some quirks), and python's type support has only gotten half-mature just recently (coming from typescript at least).
I would personally be hesitant to try something new just because django is so battle-tested at this stage, unless you just absolutely require better async support.
The only two things it lacks great support of is typing and async. However the async is actively being worked on and does work (with some quirks), and python's type support has only gotten half-mature just recently (coming from typescript at least).
I would personally be hesitant to try something new just because django is so battle-tested at this stage, unless you just absolutely require better async support.
> However the async is actively being worked on and does work (with some quirks)
I recently tried to implement it in a project using the new ORM a-methods (which AFAIK are not even async under the hood) and it resulted in an explosion of complexity bubbling up in many places in the codebase. I reverted everything to sync and re-implemented the hot functions with multi-threading... I think I'll keep to this approach until I see some good guides, codebase examples, and overall feature maturity.
I recently tried to implement it in a project using the new ORM a-methods (which AFAIK are not even async under the hood) and it resulted in an explosion of complexity bubbling up in many places in the codebase. I reverted everything to sync and re-implemented the hot functions with multi-threading... I think I'll keep to this approach until I see some good guides, codebase examples, and overall feature maturity.
Yeah I admittedly haven't used it much, our stuff was setup before they had async support at all, and our website doesn't benefit from it really.
Async database queries would in theory be more efficient if you have many long running queries, but all of ours are reasonably fast and we have plenty of dedicated headroom so there's no incentive for us to consider changing anything.
> I reverted everything to sync and re-implemented the hot functions with multi-threading...
I'm curious what your workload is? If you need the requests themselves async then you normally have gunicorn/uwsgi handle that for you. Otherwise you'd send it to a work queue. Do you have a lot of long-running queries or realtime stuff?
Hopefully django's async support improves. I love the ORM so much I use it for non-server based projects.
> I reverted everything to sync and re-implemented the hot functions with multi-threading...
I'm curious what your workload is? If you need the requests themselves async then you normally have gunicorn/uwsgi handle that for you. Otherwise you'd send it to a work queue. Do you have a lot of long-running queries or realtime stuff?
Hopefully django's async support improves. I love the ORM so much I use it for non-server based projects.
Still Django unless you're only building a simple API.
Why not a complex API?
Sure, you can build a complex API in Flask, FastAPI etc. What I actually meant is for more complex scenarios where you build API's (complex or simple) in addition to using other parts of a web framework that will inevitably come in handy, such as templating, middlewares, schedulers, etc. Then Django has all the batteries included to become productive.
If you discover a hot spot somewhere one can always spin that part off to its own service (which can very well be FastAPI to run it async) or rewrite that particular service in Go or Java. But I would not recommend premature optimization in most cases. First get your product out.
If you discover a hot spot somewhere one can always spin that part off to its own service (which can very well be FastAPI to run it async) or rewrite that particular service in Go or Java. But I would not recommend premature optimization in most cases. First get your product out.
Jetbrains Python Survey from 2022[1] has Flask, Django, Fastapi dominating the web-frameworks. Not sure how reliable this is, but I also barely see any other frameworks mentioned. So they either are in a totally different bubble, or just not popular (yet).
[1] https://lp.jetbrains.com/python-developers-survey-2022/#Fram...
[1] https://lp.jetbrains.com/python-developers-survey-2022/#Fram...
If you are doing something that is basic CRUD (which, to be honest, is most of the business world, although it's not very sexy), then Django is the best. If you want to do something that doesn't fit very well into that idea, then Flask is good for "just give me a web wrapper and get out of my way".
Have been a big Django user over the past 10 years at my startups, but we decided to do all new projects in Litestar going forwards - typing, async, and a better REST API story made it the preferred choice for us.
I guess it depends entirely on what it is that you are building - there's no one-size-fits-all but for Python for me that is still Django.
Django; none of the new-hotness one compares. This is my no-bullshit answer that comparative articles and these frameworks' home pages dodge.
Django owns! The blazingly-fast flask-alikes that come out in Python and Rust every year still can't touch it for building websites.
My only beef is that the official docs and community chats make you feel like you're an outlaw or doing things wrong if you use the raw SQL API.
Regarding this new version in particular, the feature that jumps out at me the most is the improved field choices. I've been using an odd workaround with the decorator API to tie them to python Enums.
My only beef is that the official docs and community chats make you feel like you're an outlaw or doing things wrong if you use the raw SQL API.
Regarding this new version in particular, the feature that jumps out at me the most is the improved field choices. I've been using an odd workaround with the decorator API to tie them to python Enums.
A huge part of the work I did the past year (and still do sometimes, email in my profile) was helping people transition from a full legacy django app to a lightweight django backend with rest api and a react frontend.
Django Ninja makes it especially pleasant.
I think django should really embrace this in the future. Make it easier to drop the superfluous parts; forms, templates …
I don’t know what that will look like but I don’t see a way back.
Django Ninja makes it especially pleasant.
I think django should really embrace this in the future. Make it easier to drop the superfluous parts; forms, templates …
I don’t know what that will look like but I don’t see a way back.
We are using Django "Legacy" Apps.I am puzzled by the "new" Single Page Applications (SPAs). They require extensive routing, authentication, and GraphQL integration, all of which are already handled by Django's ORM and views.Additionally, Django efficiently manages forms. The primary advantage I see in SPAs is enhanced reactivity, which certainly improves user experience. However, HTMX seems sufficient in this aspect.What would be your sales pitch to someone like me?
Twice as much code for the same functionality. They are better if you have a heavily interactive frontend. But th majority of apps don't need that. Github uses a traditional server side renderrd app, if I am not mistaken, and no on has complained about that.
Github is moving to an SPA with init-time SSR.
[deleted]
Broadly, if you're happy with Django and haven't felt the need to transition to SPA, power to you. This is the case in some industries. It's generally not the case in b2c, though, and if you haven't felt the pain yet then you likely aren't in touch enough with your customers (or you haven't connected the dots).
I don't need to sell you on the concept though I will address your comment in depth.
In general, React (especially with typescript) provides a far better developer experience than Django+Templates. The latter is extremely brittle, difficult to test, difficult to refactor, difficult to organize. The former is robust, typed, testable, easily refactored. It's simply quicker to work with React. And this has quadratic effects on how quickly work gets done: The whole stack is easier to work with, which has gains on every level such as learning pace, testing, including third party libraries, deploying, finding and fixing bugs, ...
The advantages of an SPA are an extension of this. You get to move more logic in this frontend layer. Routing at the frontend layer is mainly a performance thing: You don't get to re-download and re-render your entire page when going from, say, viewing "Produc 1" to viewing "Product 2". The whole structure is the same but the content changes = you should only get to update the content, right? If you handle routing at the frontend level, this is something you can achieve.
But routing in frontend also enables some new things you just cannot easily do without it. For example now it's trendy to have apps that open content (such as a post) which opens in a preview window/drawer (saving your current state), but if you reload the page or share the url, it loads in its own individual view. Why is it trending now? Because SPAs have enabled that behaviour.
GraphQL integration is definitely not something that is required, and in fact in ~30 client projects of this type, I've only ever done it twice, for two people it was actually relevant for.
But: You generally want an API anyway. Writing your frontend<>backend communication as an API means you can offer it to your customers as well. It's a good pattern to follow, IMO. And if you're going to have that API, then separating the frontend into an SPA is much easier, because you can use that API to drive all the communication. This makes you a user of it (dogfooding).
As for forms -- Almost all form validation should happen both in the frontend AND in the backend, this is a textbook case of something which should be (mostly) duplicated. The backend MUST validate the input at some layer, lest you end up with security issues. But the frontend SHOULD also validate it, because it's a terrible experience to fill in 15 fields, submit, then see a "please correct the errors below" message with 3 of your fields red, your chosen password gone, the captcha to re-do, and that's if you ever manage to get good errors out of the backend because sometimes it just says "This value is invalid" and you have to manually figure out what's happening there (which for normal people means you'll sometimes hear "your X form didn't work" with zero additional feedback).
I don't need to sell you on the concept though I will address your comment in depth.
In general, React (especially with typescript) provides a far better developer experience than Django+Templates. The latter is extremely brittle, difficult to test, difficult to refactor, difficult to organize. The former is robust, typed, testable, easily refactored. It's simply quicker to work with React. And this has quadratic effects on how quickly work gets done: The whole stack is easier to work with, which has gains on every level such as learning pace, testing, including third party libraries, deploying, finding and fixing bugs, ...
The advantages of an SPA are an extension of this. You get to move more logic in this frontend layer. Routing at the frontend layer is mainly a performance thing: You don't get to re-download and re-render your entire page when going from, say, viewing "Produc 1" to viewing "Product 2". The whole structure is the same but the content changes = you should only get to update the content, right? If you handle routing at the frontend level, this is something you can achieve.
But routing in frontend also enables some new things you just cannot easily do without it. For example now it's trendy to have apps that open content (such as a post) which opens in a preview window/drawer (saving your current state), but if you reload the page or share the url, it loads in its own individual view. Why is it trending now? Because SPAs have enabled that behaviour.
GraphQL integration is definitely not something that is required, and in fact in ~30 client projects of this type, I've only ever done it twice, for two people it was actually relevant for.
But: You generally want an API anyway. Writing your frontend<>backend communication as an API means you can offer it to your customers as well. It's a good pattern to follow, IMO. And if you're going to have that API, then separating the frontend into an SPA is much easier, because you can use that API to drive all the communication. This makes you a user of it (dogfooding).
As for forms -- Almost all form validation should happen both in the frontend AND in the backend, this is a textbook case of something which should be (mostly) duplicated. The backend MUST validate the input at some layer, lest you end up with security issues. But the frontend SHOULD also validate it, because it's a terrible experience to fill in 15 fields, submit, then see a "please correct the errors below" message with 3 of your fields red, your chosen password gone, the captcha to re-do, and that's if you ever manage to get good errors out of the backend because sometimes it just says "This value is invalid" and you have to manually figure out what's happening there (which for normal people means you'll sometimes hear "your X form didn't work" with zero additional feedback).
I’d also add that if you use Typescript with an OpenAPI client generator (https://github.com/ferdikoomen/openapi-typescript-codegen) it can immensely alleviate some of the biggest pain points of seperate backend and front-end. It always used to be a major pain in the ass with the amount of overhead an API change would incur - updating documentation, postman, constant communication between backend and front-end devs, etc. Now I just npm run generate, I see new API changes in my Git client and Typescript errors for code that needs updating.
Also, using a library like Tanstack Query or Rdtk Query can almost completely eliminate manual state management, and kinda makes the whole development experience feel almost like SSR.
Also, using a library like Tanstack Query or Rdtk Query can almost completely eliminate manual state management, and kinda makes the whole development experience feel almost like SSR.
> constant communication between backend and front-end devs
Curious, are you doing anything in your code-generation workflow to solve this specific pain point?
Curious, are you doing anything in your code-generation workflow to solve this specific pain point?
I should have been more specific, the codegen alleviates a large portion of back and forth that would have otherwise been spent asking the backend devs things like “why isn’t this working”, or “what has changed”. There is still a lot of communication involved, but it relates more to the business objectives and less annoying fiddly things. For my current project the backend devs are using a cumbersome enterprise stack - the one saving grace for me being that they have swagger (OpenAPI) docs. As a front-end dev the codegen really helps to shield me from a lot of implementation specific backend stuff, as if the interface changes I am going to be informed about it from the Typescript compiler. Also one really great feature is that specific values for validation, such a min/max character length are also exposed and generated with the codegen so that is also another bunch of variables that I can worry less about when I implement clientside validation.
I’d really recommend taking a look at the tool I linked. I see a bunch of end-to-end Typesafety tools mentioned like GraphQL, Protocol Buffers, etc, but they seem overly prescriptive to me, and most of the time you are gonna be working some basic REST service and an OpenApi/Swagger doc is the best you are going to get from the backend devs.
I’d really recommend taking a look at the tool I linked. I see a bunch of end-to-end Typesafety tools mentioned like GraphQL, Protocol Buffers, etc, but they seem overly prescriptive to me, and most of the time you are gonna be working some basic REST service and an OpenApi/Swagger doc is the best you are going to get from the backend devs.
Mobile
I've gone the opposite way. Started converting views to rest framework viewsets and building React components on the front end. It just created more problems. Now the React stuff is considered legacy and we're using HTMX and the bare minimum of vanilla JS when necessary.
REST Framework is frankly... flawed. Full of good ideas, but in practice, it leads to development hell unless you're very rigorous with it.
FastAPI is the gold standard, which in the Django works means Django-Ninja.
If you've been building individual React components and integrating them without going the SPA route, then while there are some upsides to that, you are doing a lot of the effort but not getting most of the benefits.
If you don't need an SPA, then you don't need an SPA. Nobody should be getting this development pattern shoved down their throats. But from what you describe, it sounds to me like you went with a bad approach altogether, so no kidding it created more problems.
(Not to make it sound like a "no true scotsman" with the whole "bad approach" thing, but this is why it's important to get people who really know their shit in driving refactors like these, and can make a strong plan ahead of time, detailing what value is brought at each and every step)
FastAPI is the gold standard, which in the Django works means Django-Ninja.
If you've been building individual React components and integrating them without going the SPA route, then while there are some upsides to that, you are doing a lot of the effort but not getting most of the benefits.
If you don't need an SPA, then you don't need an SPA. Nobody should be getting this development pattern shoved down their throats. But from what you describe, it sounds to me like you went with a bad approach altogether, so no kidding it created more problems.
(Not to make it sound like a "no true scotsman" with the whole "bad approach" thing, but this is why it's important to get people who really know their shit in driving refactors like these, and can make a strong plan ahead of time, detailing what value is brought at each and every step)
The lesson learnt is that React is an "all or nothing" type thing. You'll notice "SPA" isn't mentioned at all on the React website, but there's lots of mentions of building components. There are lots of comments around places like HN of people learning the same lesson as me. We never scoped replacing our entire UI with React and entire backend with JSON API because it seemed like there was a smooth upgrade path, but there isn't really.
As for people who know their shit, how do you think said people learnt their shit? Everyone can do what they already know. The interesting stuff is on the frontier of your knowledge. You learn by pushing that boundary and, when you fail, thinking about why it failed.
As for people who know their shit, how do you think said people learnt their shit? Everyone can do what they already know. The interesting stuff is on the frontier of your knowledge. You learn by pushing that boundary and, when you fail, thinking about why it failed.
React isn’t all or nothing… you can upgrade bit by bit, extremely incrementally. But if you’re mix and matching frameworks and paradigms together then yes expect to not get the full value.
It’s like judging Django when only using it for its utils package and saying it’s “all or nothing”. Django isn’t really all or nothing either but you won’t get its full value if you just use it to supplement Wordpress for a single endpoint or something.
It’s like judging Django when only using it for its utils package and saying it’s “all or nothing”. Django isn’t really all or nothing either but you won’t get its full value if you just use it to supplement Wordpress for a single endpoint or something.
> because it seemed like there was a smooth upgrade path, but there isn't really
You can put a React component into a non-React web page and give it data to render from however you like. Isn't that the intended path?
You can put a React component into a non-React web page and give it data to render from however you like. Isn't that the intended path?
Yes, and that is indeed what we did. But what happens is you end up with a backend awkwardly fragmented into restframework viewsets and normal Django views. Often you end up having to maintain both. And then your frontend is in two distinct "worlds" which are developed in completely different ways. Unless you finally get to having an SPA and only JSON on the server side you'll feel forever in limbo. HTMX just makes so much more sense for an existing Django project unless you can afford to stop development and go all in on React, and even then only if it's really necessary to have an SPA.
Yeah - agree that the Django path to add REST endpoints alongside HTML ones is not the best. I like Flask for this reason: it walks the line between HTML rendering and JSON responses really well, IMO.
> Now the React stuff is considered legacy
There's no point announcing things are now "legacy". Legacy is what Microsoft invented to call products they just made a competitor for, and the psychology seems the same. If it doesn't fit your needs, great. But React is useful for lots of needs.
There's no point announcing things are now "legacy". Legacy is what Microsoft invented to call products they just made a competitor for, and the psychology seems the same. If it doesn't fit your needs, great. But React is useful for lots of needs.
I didn't mean React is legacy. You can't replace a React app with HTMX in general. I just meant within my project. Those parts are now unmaintained and will be replaced when they break or if we need to change them.
Oh! Sorry - hope you enjoyed my overboard response :)
What do people like torturing themselves by duplicating code. Wouldn't it be easier to just use node all the way.
Writing hundreds of lines of JS to display a Table list, instead of HTML sprinkled with some JS
Writing hundreds of lines of JS to display a Table list, instead of HTML sprinkled with some JS
A whole stack rewrite is not always (in fact very rarely) a good idea. The backend often drives a lot of logic; in a big rewrite, the less you rewrite the more likely you are to be successful.
Too many big refactors fail because they aren’t done in value-adding steps.
Also your second paragraph isn’t in line with your first … in react you don’t write “hundreds of lines of js” for a table. You write the html as js (jsx), and sprinkle the dynamic parts on top. It’s equivalent…
Too many big refactors fail because they aren’t done in value-adding steps.
Also your second paragraph isn’t in line with your first … in react you don’t write “hundreds of lines of js” for a table. You write the html as js (jsx), and sprinkle the dynamic parts on top. It’s equivalent…
I've seen, routing boilerplate, js to make the api requests, js to modify state(redux), unit tests, interfaces, until you get to the actual table.
No thanks, I prefer to drop React and use django + htmx for ajax.
Hey, if you're happy writing html using not-quite-jinja templates that are completely impossible to test, auto-format, or even sometimes syntax highlight...
what can I say, power to you. You go, buddy.
what can I say, power to you. You go, buddy.
You can integration test, you can use the debug plugin for htmx, you can format them with vs code extensions, and there is a highlighter available, though it’s not that important seeing as how each attribute is pretty simple.
Are there any large sites that use Django Ninja?
I've been using DRF for about a decade and there hasn't been a moment of enjoyment or ease. I adore Django but wish it had an official REST contrib package. [0] With DRF dragging its feet on async (leaving it to a third-party library) I just want to quit.
I'm building a new async api soon, are there any Django Ninja case studies? I can't find anything.
[0]: Using Django..
Me in 2008 — "How do I get data from a PUT/PATCH request without a library?"
Me in 2023 — "How do I get data from a PUT/PATCH request without a library?"
I've been using DRF for about a decade and there hasn't been a moment of enjoyment or ease. I adore Django but wish it had an official REST contrib package. [0] With DRF dragging its feet on async (leaving it to a third-party library) I just want to quit.
I'm building a new async api soon, are there any Django Ninja case studies? I can't find anything.
[0]: Using Django..
Me in 2008 — "How do I get data from a PUT/PATCH request without a library?"
Me in 2023 — "How do I get data from a PUT/PATCH request without a library?"
Django Ninja just hit 1.0 a few weeks ago. I think you are going to have to be patient to find large sites using it in production.
I've never heard of anyone using it in production, period. The one thing FastAPI had going for it back when it was announced was a list of companies and groups with it deployed that minute.
Is it a "1.0 because we think it's done and you should try using it now. Maybe it'll work." Or "This is a solid 1.0 that has been tested in production. You can expect reasonable api stability."
FastAPI launched with option three: "We're going to get our friends to use it in production so we can say it's deployed by Microsoft, but, this is definitely a pre-alpha."
Is it a "1.0 because we think it's done and you should try using it now. Maybe it'll work." Or "This is a solid 1.0 that has been tested in production. You can expect reasonable api stability."
FastAPI launched with option three: "We're going to get our friends to use it in production so we can say it's deployed by Microsoft, but, this is definitely a pre-alpha."
Not a large site, but I used django-ninja in production for internal tooling at a very large game dev/publishing company. The APIs routinely handle 1000s of calls (via an integration with Dagster) for moving large amounts of data around and into a reporting system. It's rock solid and fast. I'm on v0.22 however and need to do some refactoring to move to 1.0 because of changes to the integration with Pydantic.
It is so easy to set up and use and it's at worth giving it a spin if you're curious.
It is so easy to set up and use and it's at worth giving it a spin if you're curious.
Thanks. 1,000s of calls a second/minute/day?
Because of the integration with Dagster, the calls are made when my Dagster flows run. I also send unreasonably large data payloads. Anything going into Django gets handed to a Celery batch processing job and just returns the job id (Dagster monitors for failure, too). Data pulled out of Django is paginated. Sometimes it's 1000s of calls per minute, sometimes it's none at all for hours. I realize this isn't a normal use case, though. :)
Thanks.
I am using it myself on a branch I haven't pushed to production. I would say DRF has better documentation and more packages that extend its behavior (like exporting to Excel). Ninja is a lot cleaner though, it works better with type checkers, and if you are also using FastAPI there is basically no learning curve.
Django Ninja has always looked beautiful. I've been toying with it since it was first announced, never pushed it to production tho. I've been thinking of spinning up a cluster just to dark launch it with calls from my main app to see how it performs.
It is 1.0 only because of supporting pydantic 2.0. It's not 1.0 because it's done and you should try to use it. In fact, 1.0 is unstable I don't recommend upgrading if you are running django ninja in production
There we go! Thanks, that’s the sense I got.
While I don’t use it anymore and have been out of the web dev space completely for a few years now, I personally feel I owe a lot to Django. It’s the framework behind the first software I wrote that other people actually used and depended on. While looking back at it now the first Django code I wrote was pretty awful, it’s astonishing how much the framework lets you accomplish. Without knowing much at all about web development or databases, following the Django tutorial is sufficient to get you started with a very basic web app, and you can grow from there. Couple this with the superpower that was deploying to Heroku, and it made for a fantastic introduction to web dev and shipping software to real users.
Just FYI -- there is so much mature Django and Python code out there than ChatGPT is really an excellent partner when you're building a Django project. Django is frankly the best web framework in existence, IMHO.
* if you can accept the flaws in Python for your usecase
I loooove Django, any project that I work on that isn't Django causes me to yearn for it greatly. However, there's two things that have been minorly bothering me about it:
- The complete lack of any motivation to support type hints (yes I know about stubs and the other 3rd party).
- The GraphQL situation is a mess. Graphene on again off again development and Strawberry being not quite all the way stable yet sucks compared to how baller DRF is. It's still a massive fight to get subscriptions working well. It would be nice to see the foundation throw them a bone like they did with Channels.
- The complete lack of any motivation to support type hints (yes I know about stubs and the other 3rd party).
- The GraphQL situation is a mess. Graphene on again off again development and Strawberry being not quite all the way stable yet sucks compared to how baller DRF is. It's still a massive fight to get subscriptions working well. It would be nice to see the foundation throw them a bone like they did with Channels.
Hi there! I work on Strawberry GraphQL, would be interested in sending me a list of the things that we can do better? You can send me a dm on discord or open an issue on discord, I plan to spend more time on Strawberry next year, so hopefully I can make it good for you!
Sure thing! We have migrated to Strawberry for all our projects going forward, next time I have my hands in those project guts for maintenance I'll document some and send it on.
I'm excited to try the field group templates, I expect it to make handling forms styled with Tailwind much easier.
I work in the Rails world, and perhaps my perception is colored by the big changes they tend to make, but this seems like more of a minor than a major version release? Or is this relatively big for Django?
Yes, relative minor update. Django is very mature and does most things needed, so there has not been need for major changes since about 2.0.
Django releases are now based on a schedule, so the 5.0 label wouldn't have been chosen because of significant changes.
But, I have observed that releases often look like this:
- X.0 Newer shinier features
- X.1 More refinement and minor features
- X.2 [LTS] More refinement and minor features
Which means if you stick to the point 2 releases you get longer support and subjectively more stability since the shiny new features have been polished over a couple of point releases.
But in reality these days, I think it's just whatever features are ready to ship for the scheduled release date.
Django releases are now based on a schedule, so the 5.0 label wouldn't have been chosen because of significant changes.
But, I have observed that releases often look like this:
- X.0 Newer shinier features
- X.1 More refinement and minor features
- X.2 [LTS] More refinement and minor features
Which means if you stick to the point 2 releases you get longer support and subjectively more stability since the shiny new features have been polished over a couple of point releases.
But in reality these days, I think it's just whatever features are ready to ship for the scheduled release date.
I'd be also interested to hear someone proficient have an opinion about this. A 5.0 update sounds like something big. What about the rest of the async parts in Django having been in the process of being re-written since a while, as I've heard? Also has it ever been considered to build some deeper integration of Celery for enabling and handling in-memory background job processing in a more closely and "better-integrated" way akin to Rails' active job?
Coincidentally, I am just beginning to learn Django.
I have experience with NextJS, Express and Flask.
In the past, Django had intimidated me due to having so many official-sounding files and folder structure and settings etc. So, I had just not given it too much brain cycles.
After having experience with the earlier listed frameworks, I can appreciate some of the things Django gives out of the box. It feels "industry-grade".
Hoping to make fond memories with Django just like the other experiences described here! Happy holidays everyone!
I have experience with NextJS, Express and Flask.
In the past, Django had intimidated me due to having so many official-sounding files and folder structure and settings etc. So, I had just not given it too much brain cycles.
After having experience with the earlier listed frameworks, I can appreciate some of the things Django gives out of the box. It feels "industry-grade".
Hoping to make fond memories with Django just like the other experiences described here! Happy holidays everyone!
What an incredibly powerful, robust, well-documented, carefully-designed piece of open source software. I love Django so much and I use it every day. A huge thanks to all developers and maintainers.
If someone were to look for a web developer job these days, is Django the framework to focus on if you want a project that has a decent quality of life and is easy to get a job doing? I assume it's between that and Rails.
Alternatively, if I already have a ton of web framework experience and desperately want to move on to something different, what are some natural areas to extend into to stop working for agencies making crappy websites for small businesses? I guess this is off topic but it seems like people reading this may have input
Alternatively, if I already have a ton of web framework experience and desperately want to move on to something different, what are some natural areas to extend into to stop working for agencies making crappy websites for small businesses? I guess this is off topic but it seems like people reading this may have input
React? Or back-end with NodeJS
for those keeping up with Django’s async story the biggest updates with Django 5.0 are:
The new asynchronous functions are now provided, using an a prefix: django.contrib.auth.aauthenticate(), aget_user(), alogin(), alogout(), and aupdate_session_auth_hash().
AuthenticationMiddleware now adds an HttpRequest.auser() asynchronous method that returns the currently logged-in user.
[Edit: paste wasn’t the full sentence]
The new asynchronous functions are now provided, using an a prefix: django.contrib.auth.aauthenticate(), aget_user(), alogin(), alogout(), and aupdate_session_auth_hash().
AuthenticationMiddleware now adds an HttpRequest.auser() asynchronous method that returns the currently logged-in user.
[Edit: paste wasn’t the full sentence]
Know what ChatGpT is real good at?
Writing Django.
Using that to my advantage lately.
Writing Django.
Using that to my advantage lately.
Be sure to check out the Query base classes (Func, etc), it helps getting over the choice '__prop__func' as syntax.
Been using Django starting from version 2.2 ever since then the release of new upgrades has been charming. Thanks to the team for the new improvements.
Is there a good JS/TS Django replacement? Something mature? I know a few were taking shots at it, but I truly hate Python and have a JS team
Did RedwoodJS ever take off?
can you list the features that are lacking in django?
I would point to two of the most popular plugins, Django Rest Framework (DRF) and Celery (a background task system that requires rabbitmq|kafka|redis|etc).
Both add highly sought-after features, but I believe these implementations are quite poor, complicated. Django could implement MVPs in core/contrib and vastly simplify future projects for users.
A builtin OIDC client abstraction would go a long way as well.
Both add highly sought-after features, but I believe these implementations are quite poor, complicated. Django could implement MVPs in core/contrib and vastly simplify future projects for users.
A builtin OIDC client abstraction would go a long way as well.
The worst thing about DRF is the dogmatic adherence to inexplicable class hierarchies, something that is modeled after Django class based views. I think Django would fumble a DRF implementation.
All you really need is a decent built-in JSON de/serializer for Django models. It doesn't need to be an OOP monstrosity.
Golang has that built-in to what is a simpler language than Python (e.g. no class inheritance).
The complexity of DRF greatly oversteps what it is offering.
Golang has that built-in to what is a simpler language than Python (e.g. no class inheritance).
The complexity of DRF greatly oversteps what it is offering.
I usually hear this question the other way around but there it goes.
Why should someone consider Django instead of something like Symfony or Laravel?
Why should someone consider Django instead of something like Symfony or Laravel?
Because they know, or want to know Python
Thank you, mister, but I mean from a techy point of view.
I only know laravel from skimming the docs, but I got the impression that there was not enough difference between it and Django to justify switching to a language you don't know,going either way.
That said... Does Laravel have something like Django's admin view?
That said... Does Laravel have something like Django's admin view?
I guess the equivalent would be Laravel Nova.
How does Django compare to Ruby on Rails? Any developers in here that tried/used both frameworks?
Anyone experienced performance improvements by using pypy instead of cpython with django?
Does anyone else find this obsession with expanding database-related features weird?
And django-timezone-field and others are not currently compatible, blocking upgrades.
Type hints everywhere?
No, as I understand it, the Django project's stance on type hints is that they aren't going to be added any time soon, but they are willing to accept small PRs that are needed by external type-checkers on a case by case basis. Details here: https://github.com/django/deps/pull/65
[deleted]
Assuming they used Django to publish this, it’s a bit sad that there’s no `generator` tag to give their own CMS a little love. :-/
Django isn't really a CMS. People sometimes group it in with other CMSs because it's good for rapid development of CRUD web applications, but I think most people think about a much higher level tool when they think of a CMS. It's also somewhat limiting – Django is good for building big web applications (see: Instagram, Octopus Energy) not just traditional content management based applications.
> People sometimes group it in with other CMSs because it's good for rapid development of CRUD web applications
No, it's because there's a CMS called Django CMS.
No, it's because there's a CMS called Django CMS.
django is good
just one thing
fix .select_related('child__attribute') / .values('child__attribute')
currently it removes from result set rows where 'attribute' is NULL, unlike what typical LEFT JOINs imply
just one thing
fix .select_related('child__attribute') / .values('child__attribute')
currently it removes from result set rows where 'attribute' is NULL, unlike what typical LEFT JOINs imply
I never run into this issue but isn't it that Django uses inner join for select related, so it does what it's supposed to do?
You can always prefetch related, or even use outer=True. This will return the results you expect.
You can always prefetch related, or even use outer=True. This will return the results you expect.
Django seems great but also incredibly complex.
I am never able to find any good example projects that use it with react and aren't just a toy which is bit of a bummer, because I think that would be a great stack.
I am never able to find any good example projects that use it with react and aren't just a toy which is bit of a bummer, because I think that would be a great stack.
Django makes it dead easy to take a URL route and return HTML. Obviously there's some fussing to add a script tag that points at your JavaScript file, but what exactly are you looking for beyond that? I'm not exactly sure what you're looking for beyond that (as someone who ~only writes Django+React); that's kind of it. There's no big magic, it responds to http requests with data.
For a full-on SPA (which I'm assuming is what they mean by "and aren't just a toy"), you'd also need at least frontend routing and an example how to make that play nice with Django URL routes, probably a data store (which at this point I think is just going to be redux), and most of the Django views would return JSON instead of HTML.
None of those concerns have anything to do with Django: just have Django return your HTML for all views that don't return JSON (which is to say, set the 404 to your HTML).
There's no need to use a data store like Redux. Any routing framework will work. Any react framework will work. Django has no impact on how you structure your SPA in any way! If you can build a SPA, making it work with Django is literally just "return HTML with a script tag". There's no "use React with Django" tutorials because that's literally it. If you can return HTML from a Django view, you've got everything you need for whatever React project you intend to build.
There's no need to use a data store like Redux. Any routing framework will work. Any react framework will work. Django has no impact on how you structure your SPA in any way! If you can build a SPA, making it work with Django is literally just "return HTML with a script tag". There's no "use React with Django" tutorials because that's literally it. If you can return HTML from a Django view, you've got everything you need for whatever React project you intend to build.
In case you're interested, Firefox Relay uses that stack and is open source: https://github.com/mozilla/fx-private-relay/
Posthog uses react for front-end and django for back-end. https://posthog.com/handbook/engineering/project-structure
I like Django rest framework a lot. It was really easy to make something with react and call Django directly however the templating engine is also great. It’s so strange people still use rails
> It’s so strange people still use rails
Why? What makes Django better? (Genuinely curious.)
Why? What makes Django better? (Genuinely curious.)
I never used Rails, but people who use both said that thy were pretty similar. Python had the advantage of scientific libraries (which was useful for what I was building), while Rails was a bit more web dev focused.
Rails does seem to have fallen out of favor over the last decade, while Django enjoyed a more steady level of popularity. I guess Python is a more popular language.
Rails does seem to have fallen out of favor over the last decade, while Django enjoyed a more steady level of popularity. I guess Python is a more popular language.
I don't think Rails is any less favoured than Django - the hype moved on from back end oriented web frameworks in general though.
Rails had a higher level of initial hype though, so maybe more of that moved on to other things leaving it closer to Django that had a slower decline.
Both projects are solid mature choices though - the downside of that might be attracting enough new/younger devs. Choice comes down more to Ruby vs Python depending on which one your team knows better or if you need other libraries from that language.
Rails had a higher level of initial hype though, so maybe more of that moved on to other things leaving it closer to Django that had a slower decline.
Both projects are solid mature choices though - the downside of that might be attracting enough new/younger devs. Choice comes down more to Ruby vs Python depending on which one your team knows better or if you need other libraries from that language.
Yes, Rails definitely had more initial hype, which in turn led to a bigger decline, while Django remained more steady with it's popularity. I see a lot less Rails jobs than I used to. I might b wrong but I don't see much Ruby use outside of Rails.
Rails is ruby… so that’s one thing
Rails is much harder to containerize
Rails structure is extremely messy and you have to learn how to do it the rails way. Python in general is easier to hire for and is just better
Rails is much harder to containerize
Rails structure is extremely messy and you have to learn how to do it the rails way. Python in general is easier to hire for and is just better
You should learn a bit about Rails. It wont be strange that people still use it.
Another boring release without much innovation. I wonder what's stopping Django from releasing more useful features like other frameworks are doing. Maybe the team is stuck in the past.
They've been trying to improve forms for a long time but it still sucks. I think they should just remove it at this point and let external packages solve the problem.
They've been trying to improve forms for a long time but it still sucks. I think they should just remove it at this point and let external packages solve the problem.
> Another boring release without much innovation
That's a good thing. A couple of articles related to the topic.
https://boringtechnology.club/
https://www.david-dahan.com/blog/10-reasons-mvc-frameworks-a...
That's a good thing. A couple of articles related to the topic.
https://boringtechnology.club/
https://www.david-dahan.com/blog/10-reasons-mvc-frameworks-a...
Not much no, but both the GeneratedField and db_default would be useful in almost all projects I've ever implemented in Django.
Good for you but they're niche features that most developers will never use. I certainly won't.
That's why I switched to NextJS anyway. Django's implementing features voted by the board and companies who fund the project the most. They don't care about end users anymore.
That's why I switched to NextJS anyway. Django's implementing features voted by the board and companies who fund the project the most. They don't care about end users anymore.
can you list the features you mentioned that is lacking in django?
I’m revisiting a business idea I was working on for a couple years, before I sought and found employment in the industry (where I used Java for a couple years, then Elixir for a couple more). My project was built with Django and Django REST Framework, and Ember on the client-side. 6 years later, the Django side needed minimal changes and is up and running (I jumped all the way from 1.11 to 5.0 beta).
Meanwhile, the Ember part is “lost in time… like tears in rain”. I tried everything, downloading older versions of Node and even the now-deprecated Bower. I don’t fault Ember (which is actually the most stable of the major JS client frameworks). But the JS (especially Node) ecosystem is beyond redemption in my eyes.
For my rewrite of the client, I’m going to skip the drama and just use htmx. Render Django templates server-side, include a single JS script, thrown in some HTML attributes, distinguish between full page requests vs. requests for a partial with updated data, and call it a day. No TypeScript, no Webpack, none of that nonsense. If I need special interactivity I can throw in some hyperscript.
At work I’ve used Elixir/Phoenix/LiveView and it’s revolutionary, truly awesome tech. But to get to market I would rather not have to customize an auth system and build a decent admin interface myself (I tried Ash; its auth and admin are not mature enough to be compared to what “just works” with Django). Yeah, it won’t be as scalable as a Phoenix app, but to me, Django seems like the most clean and rapid way to get to a point where you’ll actually need scalability.