Comment by haney | Hacker News Reader

Comment by haney | Hacker News Reader

Parent Full thread

This is a totally acceptable approach but not one I personally would prefer.

One of the advantages of django apps is having cleanly divided responsibility. For example, I worked on a large django project that had 70+ apps and several dozen developers. Engineers were encouraged to create new apps for new functionality. In some cases apps could be cleanly pulled out of the code base and converted into a library. The ability to pull libraries out of the "main" repo also meant that certain teams could more easily "own" parts of the codebase. At a different company we actually decided to split our monolith into 3 separately deployed services and it was pretty easy for us to copy the appropriate Django apps into new services.

In general I've found that early in a company's life it is much easier to manage the complexity of a monolith and I've found that Django's app abstraction allows developers to communicate which parts of the codebase shouldn't be overly intimate with one another, which at least gives you a hope of breaking pieces into separately deployable libraries or services as the company/project scales up.

The problem I have with the multi-app approach is that it's really hard to change apps once you've defined them; migrating a model from one app to another is a massive PITA. Because of this, in my experience you pay a high price if you don't define the service boundaries correctly first try. The whole idea behind the "build the monolith first" advice is that in general you don't really know what the appropriate boundaries are going to be ahead of time, so I view this as problematic.

Also over the last few years I've hit multiple schema-migration bugs that only occur on relations spanning apps, and no such bugs within single apps, so there's definitely a "less well-trodden path" argument against multiple apps.

Finally migration squashing didn't work well when I tried it on my multiple-app project; it wasn't able to squash past the first foreign key to another app. This might have improved in the last couple releases.

I've not worked on a project as large as the one you describe, so I'm open to the possibility that at that scale there are new problems that crop up (e.g. managing a single migrations directory could be fun with that many developers), but I'd guess that most developers won't hit that scale, and yet the common wisdom for getting started is to try to split out small apps early, which I consider harmful.

(I'm working on a big Scala Application, but this was migrated from a large Django Application) well in a large project the migrations folder is not your problem. no matter if it is big or small. It's mostly the seperation of concern that can kill your ability to add code to your application. Once your application gets big it's really hard to have a good structure to scale further. The correct "app layout" is pretty important and I think the app structure is a good way to structure __most__ applications.

> Once your application gets big it's really hard to have a good structure to scale further

Agreed - I would note that there is nothing stopping you from having good structure (with multiple independent/encapsulated services/apps) inside a single Django "app" (as the OP suggests).

I couldn't agree more with your approach. If you maintain highly cohesive/loosely coupled django apps in your greenfield monolith, it's relatively trivial to switch to SOA/microservices as you scale the software with your organization.

Reply on news.ycombinator.com