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

Tips for Building High-Quality Django Apps at Scale

blog.doordash.com

Post reply on HN
Print view View original

51–60 of 125 posts

Re: Tips for Building High-Quality Django Apps at Scale

#51

Post by tinix »

asdfgadsfgasfdg wrote: post #39
tinix wrote: post #30

Earlier quoted context omitted.

> I'm not sure why you put quotes around migrations as if it's some alien, obscure or weird feature. If you've never written a web application that needs migrations then you're not writing the kinds of applications (or indeed any 'serious' application) that would benefit from Django IMO. I have been programming for almost 15 years, and have never once needed to use migrations. I have worked on projects for multiple y…

How do you add columns to your db? Do your requirements never change? I am fully capable of doing everything done with migrations with SQL - but I always use migrations (even for custom sql outside of the ORM's capability). Why? because then we have a record of the schema state at any given moment (that is in sync with the application code at that point) and how it got to where it is now.

If you're leaning on migrations often, with SQL, then I think you should not be using SQL, obviously (or you're just doing something wrong) Or, one should use a SQL database that allows more abstract data types (like JSON blobs in Postgres)

Re: Tips for Building High-Quality Django Apps at Scale

#52

Post by rhizome »

tinix wrote: post #37
tobltobs wrote: post #32

Earlier quoted context omitted.

You get your DB model 100% correct the first time, always? Even years later your DB model is able to accommodate all those always changing business requirements?

Yeah, pretty much. Haven't had a problem yet where I needed automated migrations, and I have been doing this for years upon years upon years. Like I said, if you're leaving heavily on migrations, you're doing something wrong.

Haven't had a problem yet where I needed automated migrations, and I have been doing this for years upon years upon years.

Just out of curiosity, have you had to maintain/modify any of these apps over these years and years? If so, without any schema changes?

Re: Tips for Building High-Quality Django Apps at Scale

#53

Post by ensignavenger »

linkmotif wrote: post #35

Django is not meant to be run at scale. At least not horizontal scale. If you're not going to use the ORM, which prevents you from scaling horizontally, why are you using Django? Django can be scaled by getting large instances with lots of RAM, which is quite affordable these days. It can also be scaled with caching. But if you want horizontal scaling, don't use Django. That's not what it's for.

How does the ORM prevent horizontal scaling?

Re: Tips for Building High-Quality Django Apps at Scale

#54

Post by falsedan »

tclancy wrote: post #40
Osmose wrote: post #31

Earlier quoted context omitted.

> I never hit a point where designing the project in apps became a problem. The article literally describes why this is a problem in the first place. Cross-app model relations are a PITA, and splitting "sections" of your site into separate apps often has you end up with cross-app relations. The more general point here is that: The functional separation between Django apps and the logical separation between "parts" of…

>Cross-app model relations are a PITA A PITA how? They say they ran into migration issues due to the apps approach but it sounds like they ran into issues due to the sheer number of migrations happening across a bunch of developers. That sounds like a likely problem on big teams, but I don't think it's one best solved by not using the app approach and I don't think it's one whose underlying problem is ForeignKeys to…

Don't see how up-front modelling would have predicted the high planes of Unicode & MySQL's utf8 encoding being supplanted by utf8mb4 so users of your product could message taco emoji to each other.

I have an agenda against Getting It Right First Time, Every Time, since it encourages brittle code that's a struggle to adapt to new, seemingly-similar use cases.

Re: Tips for Building High-Quality Django Apps at Scale

#55

Post by falsedan »

t0mbstone wrote: post #38
cwisecarver wrote: post #4

I've got more than 5 years of experience with Django on a number of teams and at a couple of companies and in my experience almost everything in this article is completely incorrect. The only things I would agree with is the point about project layout and avoiding django's squashmigrations for the truncate the migrations table, delete the migrations, and create a new initial migration. Practically everything else in…

It's not really helpful when people come along and just say, "That's wrong", without explaining why ...

I agree, but can you elaborate?

edit: 100% earnest request here

Re: Tips for Building High-Quality Django Apps at Scale

#56

Post by randomsearch »

mi100hael wrote: post #47
randomsearch wrote: post #7

Earlier quoted context omitted.

The polls app example is given in the introductory Django tutorial...

Yes, that's what I said...?

Sorry, misread that line.

Point being, how many examples do you have where someone writing a Django site is going to reuse their own apps?

Re: Tips for Building High-Quality Django Apps at Scale

#57

Post by afarrell »

tinix wrote: post #37
tobltobs wrote: post #32

Earlier quoted context omitted.

You get your DB model 100% correct the first time, always? Even years later your DB model is able to accommodate all those always changing business requirements?

Yeah, pretty much. Haven't had a problem yet where I needed automated migrations, and I have been doing this for years upon years upon years. Like I said, if you're leaving heavily on migrations, you're doing something wrong.

Have you had a project where you needed automated testing?

Re: Tips for Building High-Quality Django Apps at Scale

#58

Post by afarrell »

tinix wrote: post #51
asdfgadsfgasfdg wrote: post #39

Earlier quoted context omitted.

How do you add columns to your db? Do your requirements never change? I am fully capable of doing everything done with migrations with SQL - but I always use migrations (even for custom sql outside of the ORM's capability). Why? because then we have a record of the schema state at any given moment (that is in sync with the application code at that point) and how it got to where it is now.

If you're leaning on migrations often, with SQL, then I think you should not be using SQL, obviously (or you're just doing something wrong) Or, one should use a SQL database that allows more abstract data types (like JSON blobs in Postgres)

So where is your data model enforced if not in your tables?

Re: Tips for Building High-Quality Django Apps at Scale

#59

Post by benwilber0 »

linkmotif wrote: post #35

Django is not meant to be run at scale. At least not horizontal scale. If you're not going to use the ORM, which prevents you from scaling horizontally, why are you using Django? Django can be scaled by getting large instances with lots of RAM, which is quite affordable these days. It can also be scaled with caching. But if you want horizontal scaling, don't use Django. That's not what it's for.

There's nothing really inherent to Django that prevents it from scaling horizontally, not even the ORM. For the typical SQL read-heavy workload it will scale as well as anything else depending on the scalability of the backing RDBMS. Should always use proper HTTP response caching with something like Varnish or via 3rd-party CDN where possible.

Re: Tips for Building High-Quality Django Apps at Scale

#60

Post by randomsearch »

marcosdumay wrote: post #49
randomsearch wrote: post #2

I'm so glad to see the mention of "app" directories here. I've only dabbled in Django development, but I've always thought the desire to divide things into apps didn't really make any sense. It felt like the developers of Django had said "well, intuitively, there must be some unit of reuse at this level" and then stuck the notion of apps in there in an attempt to provide that reuse. This seems to me to be somewhat un…

> why not make the reuse optional? Well, it is optional. You can just not divide you stuff and place everything inside the main app. But notice the article recreates the same layer of reuse inside the main app, and got some extra problems because of it (renaming the tables is probably caused by this). Django may need an extra paragraph at the tutorial, telling how it is ok to place everything on the main app when eve…

> Well, it is optional

What I mean is, you still have to have a "main" app. Why? I don't want to reuse it. So I don't want an "app". I just want to build my website. Stop making me put things in an unnecessarily complicated directory hierarchy. If it were Java, I wouldn't think twice about it, but it doesn't seem Pythonic.

> reverse Dunning-Kruger

Good question! Probably... illusory inferiority AKA imposter syndrome. I assumed Django knows best, but maybe it doesn't.

Post reply on HN