Interesting advice about just having one "app" for the entire website. Makes sense to me.
Also, re "Avoid Fat Models":
> This pattern can be kind of awkward if you have some logic that doesn’t really need to operate on a full model instance fetched from the database, but rather just needs the primary key or a simplified representation stored in the cache. Additionally, if you ever wish to move off the Django ORM, coupling your logic to models is going to complicate that effort.
Having built a few Django apps at a lower scale than Doordash, the battle scars they have around migrations are very, very real as a codebase grows. You don't have to be at web scale to get into cross-app migration pains... and even with a single developer the pain of the makemigrations race condition is real (context switching hurts in all the ways). If you have to come away with any one specific action item, pay attention to what they say here.
Beyond that, there are some landmines around caching beyond the model scope. In a multitenant application, be very, very careful using the cache decorator at the view layer. You can get some nasty cross-contamination. The test framework also doesn't manage separation of caches when doing parallel tests, so you can get some serious oddities that are painful to figure out the cause of in parallel tests with caching.
I'd also love to hear how they manage keeping the test framework fast, clean, and reliable... assuming they use django's test runner. There's a lot of 'best practices' you pick up along the way w.r.t. keeping tests performant and valuable.
I'm working on a +500k loc Django codebase that is a single app (but really should be 20-50 apps). It's a pain in the ass to work with. It is turning an already complex monolith into a more complex monolith. New developers that join, struggle pretty much forever. Often leave, citing the uncessary complexity. Everything is "legacy" (this project started with Django 1.4), so using new tests, approaching code in a new way is out of the question, unless you wan't to refactor all the code. Perhaps it's a organizational issue, but its definitely one of the biggest points of frustrations.
They absolutely do have a point when it comes to the positives of using one "app". But the well meant advice of being careful, doing this or that to avoid the problems named above; unfortunately don't scale (at least from my experience). If I am ever tasked to take over a Django codebase that is a single app, instead of lets say 5-10. My first priority will be to break this up in smaller apps before actually doing any actual work.
4 comments
[ 3.0 ms ] story [ 21.6 ms ] threadAlso, re "Avoid Fat Models":
> This pattern can be kind of awkward if you have some logic that doesn’t really need to operate on a full model instance fetched from the database, but rather just needs the primary key or a simplified representation stored in the cache. Additionally, if you ever wish to move off the Django ORM, coupling your logic to models is going to complicate that effort.
Beyond that, there are some landmines around caching beyond the model scope. In a multitenant application, be very, very careful using the cache decorator at the view layer. You can get some nasty cross-contamination. The test framework also doesn't manage separation of caches when doing parallel tests, so you can get some serious oddities that are painful to figure out the cause of in parallel tests with caching.
I'd also love to hear how they manage keeping the test framework fast, clean, and reliable... assuming they use django's test runner. There's a lot of 'best practices' you pick up along the way w.r.t. keeping tests performant and valuable.
They absolutely do have a point when it comes to the positives of using one "app". But the well meant advice of being careful, doing this or that to avoid the problems named above; unfortunately don't scale (at least from my experience). If I am ever tasked to take over a Django codebase that is a single app, instead of lets say 5-10. My first priority will be to break this up in smaller apps before actually doing any actual work.