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

Some notes on starting to use Django

jvns.ca

Post reply on HN
Print view View original

51–60 of 145 posts

Re: Some notes on starting to use Django

#51

Post by sgt »

compounding_it wrote: post #43
sgt wrote: post #33

Earlier quoted context omitted.

What does significantly complex mean though? You have to make sure you understand the queries made by the ORM, avoid pitfalls like SELECT N+1 queries and so on. If you don't do this, it'll be slow but it's not the ORM's fault - it's that of the programmer.

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

You can absolutely scale Django.

The framework itself is not the limiting factor. The main constraint of performance usually comes from Python itself (really slow). And possibly I/O.

There are well established ways to work around that. In practice, lots of heavy lifting happens in the DB, can you can offload workloads to separate processes as well (whether those are Python, Go, Rust, Java etc).

You need to identify the hotspots, and blindly trusting a framework to "do the job for you" (or for that matter, trusting an LLM to write the code for you without understanding the underlying queries) is not a good idea.

I'm not saying you are doing that, but how often do you use the query planner? Whenever I've heard someone saying Django can't scale, it's not Django's fault.

> When you start to run into scaling problems, your solution is within that framework and that becomes a limiting factor from my experience.

Using Django doesn't mean that everything needs to run inside of it. I am working on an API that needs async perf, and I run separate FastAPI containers will still using Django to maintain the data model + migrations.

Occasionally I will drop down to raw SQL, or materialized views (if you are not using them with Django, you are missing out). And the obvious for any Django dev; select_related, prefetch_related, annotate, etc etc.

Re: Some notes on starting to use Django

#52

Post by tclancy »

sgt wrote: post #51
compounding_it wrote: post #43

Earlier quoted context omitted.

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

You can absolutely scale Django. The framework itself is not the limiting factor. The main constraint of performance usually comes from Python itself (really slow). And possibly I/O. There are well established ways to work around that. In practice, lots of heavy lifting happens in the DB, can you can offload workloads to separate processes as well (whether those are Python, Go, Rust, Java etc). You need to identify t…

Yeah, I don’t get the issues here. I’ve led projects that served millions of requests a day, had dozens of apps and while there are always going to be pain points and bottlenecks, nothing about the framework itself is a hinderance to refactoring. If anything, Django plus good tests made me much braver about what I would try.

Re: Some notes on starting to use Django

#53

Post by cuu508 »

wiredfool wrote: post #37
hansonkd wrote: post #11

Earlier quoted context omitted.

Its crazy to me after all these years that django-like migrations aren't in every language. On the one hand they seem so straightforward and powerful, but there must be some underlying complexities of having it autogenerate migrations. Its always a surprise when i went to Elixir or Rust and the migration story was more complicated and manual compared to just changing a model, generating a migration and committing. In…

There are some subtle edge cases in the django migrations where doing all the migrations at once is not the same as doing migrations one by one. This has bitten me on multiple django projects.

Can you give an example how this would happen?

Re: Some notes on starting to use Django

#54

Post by skylurk »

dgroshev wrote: post #46
interroboink wrote: post #6

Django aside, I think this is a really important point: Being able to abandon a project for months or years and then come back to it is really important to me (that’s how all my projects work!) ... It's perhaps especially true for a hobbyist situation, but even in a bigger environment, there is a cost to keeping people on hand who understand how XYZ works, getting new people up to speed, etc. I, too, have found found…

"Cold-blooded software" is a great term for that https://dubroy.com/blog/cold-blooded-software/ (HN: https://news.ycombinator.com/item?id=46488261 )

If you know what you are doing, you can hibernate other kinds of tortoises by placing them in a fridge (as opposed to a freezer). One of my friends does this with their Russian tortoise.

If you need to travel, make sure you have someone reliable who can check on them, in case of a power outage.

Re: Some notes on starting to use Django

#55

Post by otherme123 »

tmarice wrote: post #48

After working with Django for 8 years, I find it hard to move on to anything else. It's just the right amount of magic, and just the right amount of flexibility, and it's just such a joy to work with. Re: Django is OK for simple CRUD, but falls apart on anything complex - this is just untrue. I have worked in a company with a $500M valuation that is backed by a Django monolith. Reporting, recommender systems, file in…

> Recently I had the misfortune of doing a contract on a classic SPA project with Flask and sqlalchemy on the backend and React on the frontend, and the amount of code necessary to add a couple of fields to a form is boggling.

Same here, and the reason to do all the Flask + SQLAlchemy + React was to keep things simple, as they are simple tools but Django is a complex tool. In particular the Flask part was juggling plugins for admin, forms and templates that Django already has included. But yeah, I am sure it is easier to code and to mantain because Flask is made for simple sites :/.

Re: Some notes on starting to use Django

#56

Post by wiredfool »

cuu508 wrote: post #53
wiredfool wrote: post #37

Earlier quoted context omitted.

There are some subtle edge cases in the django migrations where doing all the migrations at once is not the same as doing migrations one by one. This has bitten me on multiple django projects.

Can you give an example how this would happen?

Ok, from memory --

There's a pre, do and post phase for the migrations. When you run a single migration, it's: pre, do, post. When you run 2 migrations, it's: pre [1,2], do: [1,2], post: [1,2].

So, if you have a migration that depends on a previous migration's post phase, then it will fail if it is run in a batch with the previous migration.

When I've run into this is with data migrations, or if you're adding/assigining permissions to groups.

Re: Some notes on starting to use Django

#57

Post by ndr »

jgavris wrote: post #10

The Django ORM / migrations are still basically unmatched in happiness factor.

I found it very lacking in how to do CD with no downtime.

It requires a particular dance if you ever want to add/delete a field and make sure both new-code and old-code work with both new-schema and old-schema.

The workaround I found was to run tests with new-schema+old-code in CI when I have schema changes, and then `makemigrations` before deploying new-code.

Are there better patterns beyond "oh you can just be careful"?

Re: Some notes on starting to use Django

#58

Post by senko »

ndr wrote: post #57
jgavris wrote: post #10

The Django ORM / migrations are still basically unmatched in happiness factor.

I found it very lacking in how to do CD with no downtime. It requires a particular dance if you ever want to add/delete a field and make sure both new-code and old-code work with both new-schema and old-schema. The workaround I found was to run tests with new-schema+old-code in CI when I have schema changes, and then `makemigrations` before deploying new-code. Are there better patterns beyond "oh you can just be care…

You can do three stage:

1. Make a schema migration that will work both with old and new code

2. Make a code change

3. Clean up schema migration

Example: deleting a field:

1. Schema migration to make the column optional

2. Remove the field in the code

3. Schema migration to remove the column

Yes, it's more complex than creating one schema migration, but that's the price you pay for zero-downtime. If you can relax that to "1s downtime midnight on sunday", you can keep things simpler. And if you do so many schema migrations you need such things often ... I would submit you're holding it wrong :)

Re: Some notes on starting to use Django

#60

Post by dotancohen »

alansaber wrote: post #44
sriram_malhar wrote: post #25

Earlier quoted context omitted.

I'm finding that in this build fast and break things culture, it is hard to revisit a project that is more than 3 years old. I have a couple of android projects that are four years old. I have the architecture documented, my notes (to self) about some important details that I thought I was liable to forget, a raft of tests. Now I can't even get it to load inside the new version of Android Studio or to build it. There…

Build fast and break things works great if you're the consumer, not the dev polishing the dark side of the monolith (helps if you're getting paid well though)

As a consumer, I can not remember any feature that I was so enamored about having a week earlier than I otherwise would have, at the expense of breaking things.
Post reply on HN