Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 5.0

djangoproject.com

Post reply on HN
Print view View original

131–140 of 237 posts

Re: Django 5.0

#131

Post by kbrannigan »

scrollaway wrote: post #24

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…

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

Re: Django 5.0

#132

Post by [deleted] »

collyw wrote: post #79
number6 wrote: post #46

Earlier quoted context omitted.

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…

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.

[deleted]

Re: Django 5.0

#133

Post by har777 »

fbdab103 wrote: post #128
har777 wrote: post #113

Earlier quoted context omitted.

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 middlew…

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.

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.

Re: Django 5.0

#135

Post by djstein »

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]

Re: Django 5.0

#136

Post by bdzr »

har777 wrote: post #48
DarkNova6 wrote: post #11

Earlier quoted context omitted.

> 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...

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.

FWIW Sentry has recently (within the last year or so) rolled out support for N+1 monitoring as well.

Re: Django 5.0

#137

Post by Klonoar »

dinkleberg wrote: post #64
ralmidani wrote: post #35

Django made me fall in love with programming 13 years ago, and since then it has always had a special place in my heart. 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, th…

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 quit…

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.

Re: Django 5.0

#138

Post by gen220 »

DarkNova6 wrote: post #11
h4kor wrote: post #3

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 mor…

> 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...

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.

Re: Django 5.0

#139

Post by bdcravens »

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?

Re: Django 5.0

#140

Post by crucialfelix »

jmduke wrote: post #44
amir_karbasi wrote: post #43

Earlier quoted context omitted.

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!)

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.

Post reply on HN