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

111–120 of 125 posts

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

#111

Post by gjjrfcbugxbhf »

dang wrote: post #67
orf wrote: post #41

Earlier quoted context omitted.

> I have been programming for almost 15 years, and have never once needed to use migrations. > Have I ever had to add a column to a database? Absolutely, ... then you've used a migration. A statement like "I've never once had to use a migration" is so obviously incorrect that it's comical. Your contradiction two lines down makes it more so. The rest of your comment is fairly misinformed about a few things, full of FU…

Please keep this kind of programming flamewar off HN. If someone is wrong and you want to explain how, do so civilly. We've unfortunately had to warn you a bunch of times already about being uncivil on HN. This process isn't infinite and ends in an account getting banned, so would you please fix this?

The gp was being extremely provocative with their generic and missinformed insults...

The person you are warning was robust in their response but sometimes robustness is needed in a civilised debate.

The I think that this warning is misplaced and makes hn a worse site.

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

#113

Post by allover »

tinix wrote: post #94
allover wrote: post #64

Earlier quoted context omitted.

Okay, so you changed the DB schema in your 'dev' environment to add a column. 1. In what manner/format do you define or commit the change to VCS so it is in sync with the corresponding code change (that uses the new column)? 2. What happens when a teammate comes to deploy that schema change to production? 3. What happens when we need to roll back production to some previous commit? The need to rollback may/may-not re…

1. Change model code to add the new field, test, and commit it to version control. Then it's merged to staging, where it's tested in a production-like environment with a recent production data snapshot. After that's approved, it goes to master/production servers. 2. git pull then restart some wsgi/worker processes 3. git checkout to desired revision and restart some wsgi/worker processes It's perfectly fine to have m…

You missed the point of all those questions (e.g. in 2 you don't mention how the schema change gets applied to the prod database). Unfortunately I'm frankly out of patience explaining any further, so we'll have to leave it there.

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

#114

Post by St-Clock »

"Don’t cache Django models"

This is too broad to be good advice. A typical solution to stale models is to increment a cache version key, effectively invalidating the old cache.

Version keys can be coarse- or fine-grained. For example, you may have one version key for the entire application (supported by Django by default) and one version key per model or application (you have to roll your own solution). If your app's models change, you can increment the app version key and the next time you try to fetch a model instance from the cache, you will miss and instead fetch the instance from the DB.

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

#115

Post by andybak »

randomsearch wrote: post #61
Osmose wrote: post #34

Earlier quoted context omitted.

Where app directories are incredibly useful is in Django library development. They're a really convenient way to hook in models, static files, template helpers, etc. to an existing Django site, without forcing users to do a bunch of setup work when integrating your library. It's not a coincidence that most Django libraries have a very similar setup: 1. Install the package 2. Add the package to settings.INSTALLED_APPS…

Yeah, I agree. Makes sense for libraries. So keep that separate for library writers, don't expose me to the complexity of that.

The benchmark I use is "Is it probable that this app might become shared between projects?"

Using a Django 'app' for this makes sense. If it's generic enough that I might consider moving it into it's own repo then it's probably not going to be heavily intertwined with the rest of the project.

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

#116

Post by tclancy »

falsedan wrote: post #54
tclancy wrote: post #40

Earlier quoted context omitted.

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

I don't understand how that first sentence is relevant. How would using apps organization vs the approach described in the article protect you from making the decision to change your database's underlying encoding?

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

#117

Post by collyw »

tinix wrote: post #44
collyw wrote: post #43

Earlier quoted context omitted.

I'd like to know what I am doing wrong, as I use migrations all the time. The option is change the database later (and use migrations) or write a whole ton of crappy code to avoid using them. I have tried both ways and usually migrations work better.

I dunno what to tell you without specific details about your application and environment in general. Clearly, you need a better system architecture if you're having to do migrations constantly.

So requirements are never added / changed in your systems? Thats usually why I need migrations.

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

#118

Post by ralmeida »

Alex3917 wrote: post #85
mabcat wrote: post #70

Earlier quoted context omitted.

Is there a good place or pattern for service methods in Django? I've got some very fat models right now, and it's a DRY improvement over having the fat in the views, but like you say it takes a lot of effort to trace what's going on.

Let's say you're following the approach of breaking down your project into separate apps, so you have an app called user_accounts. This app would be a folder containing files like: views.py, services.py, models.py, test_views.py So in views.py you'd have a User class, with: A POST method that calls services.create_user(username, email_address, password) A GET method that calls services.get_user_profile(request.user)…

That's almost exactly what I do, except for using a big monolithic app for the entire backend (called "core"), and making "services" a package with several modules inside.

It also resembles very much what I see in Java projects which use DDD (Domain Driven Design).

What's your take on the article's point that you should have fewer rather than more Django apps (citing the problem of inter-app-FKs)?

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

#119

Post by mi100hael »

randomsearch wrote: post #107
soperj wrote: post #88

Earlier quoted context omitted.

I reuse my own apps constantly, whenever I do new sites.

Excellent - could you give some examples of what you reuse? I'm interested in whether this is a worthwhile abstraction in the general case, or whether for most people (like me and the post) it's an unhelpful complication.

It's a worthwhile abstraction for any generic feature that isn't specific to the one project you're working on:

- User profiles

- Content management/publishing

- Messaging and chat

- Searching your database

- Admin

- Analytics on your database

Segmenting into apps makes the most sense when there are no cross-app dependencies on migrations: additional read-only capabilities on your existing models in another app, or new capability using entirely new, stand-alone models.

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

#120

Post by Alex3917 »

ralmeida wrote: post #118
Alex3917 wrote: post #85

Earlier quoted context omitted.

Let's say you're following the approach of breaking down your project into separate apps, so you have an app called user_accounts. This app would be a folder containing files like: views.py, services.py, models.py, test_views.py So in views.py you'd have a User class, with: A POST method that calls services.create_user(username, email_address, password) A GET method that calls services.get_user_profile(request.user)…

That's almost exactly what I do, except for using a big monolithic app for the entire backend (called "core"), and making "services" a package with several modules inside. It also resembles very much what I see in Java projects which use DDD (Domain Driven Design). What's your take on the article's point that you should have fewer rather than more Django apps (citing the problem of inter-app-FKs)?

So my startup is built the way you describe, in terms of just having one main app, and I personally prefer this style.

The basic argument in favor of breaking down the Django project into multiple apps is that it makes the components more decoupled and reusable. But personally I think this is bullshit. If you want your apps to be reusable and decoupled then you need to put a ton of time into architecting them this way, the idea that you're going to get these benefits just from putting stuff into different folders is magical thinking. It seems like pretty much the textbook example of cargo cult programming.

That said for the client I'm currently working for, the decision was made to do it the 'standard Django way' in terms of breaking it into multiple apps. So far I haven't run into any issues here. I like it slightly less because I think having all the views in the views folder, and all the services in the services folder makes folks more likely to reuse code just by making it easier to find. But yeah, so far no real problems, but I'm also not expecting to see any magical benefits either.

Post reply on HN