The Impossible Structuring Decisions
How to structure your web app’s code base is a difficult problem, even more so when there are full stack frameworks involved.
Take Django, for instance. “Apps” is one of its cornerstones, and the docs say they allow you to create reusable, pluggable modules. GREAT! A project structure that is mature, well-designed, and well understood . . . what more does a developer want, right?!
Unfortunately, it doesn’t really work out that well in practice. The first problem is the project structure itself, while the second problem is the general architecture.
Let’s take project structure first. It feels nice and intuitive to break my SaaS app into smaller “modules”. Without even thinking about it, you end up naming these modules in alignment with the understanding of the business folks. So, when they say the “invoice” modules needs this and this change, it maps 1:1 to your programming model. There are modules for everything — clients, email, file uploads, pdf generation, departments, procurements, ad infinitum — and more can be added as per need.
Except you run into major problems later on and realize it was a bad, bad idea. Here’s an article that I came across recently, which details their woes with multiple “apps” and migrations. I’m too lazy to reproduce their story here, so feel free to follow the link and read.
But one piece of advice that articles provides makes me sad:
If you are planning to migrate to microservices down the line, I can imagine that “apps” might be a useful construct to define precursors to a future microservice.
Nobody knows in advance what they are going to transition into in the future. Besides, Microservices is a whole different can of worms that is better left unopened. All in all, it seems a much better idea to not break your code into “apps”.