111–120 of 237 posts
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'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?
Earlier quoted context omitted.
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.
Have a pitch on what differentiates this from django-toolbar? Just the focus on query count monitoring?
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.
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…
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.
Earlier quoted context omitted.
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.
+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.
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...
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.
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.
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...
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.
Guess who had to refactor this mess and steer away from catastrophy.
I’m haunted to this day.
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…
Earlier quoted context omitted.
> 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…
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.