Whenever someone asks if they should start with an umbrella application or not the common answer I see here is that one should start with a monolith and go to an umbrella when it is appropriate, otherwise one may introduce complexity when it could just as well be avoided.
I would like to know specifically what that complexity is and some examples. The areas I guess may be more cumbersome would be:
Deployment. How to deploy only 1 app vs the entire umbrella.
Database management and sharing/migrations between applications.
Testing. Additional configuration to test the entire umbrella vs independent applications.
Sharing code across applications.
I’d love to hear the challenges you’ve run into and how you overcame them.
I have built with both broad module trees under a single project and with umbrella projects, with narrow module trees in multiple apps. Importantly, they are called umbrella projects. They unify the mix/project aspect of things, a common set of deps, a common _build, a common config (now that the umbrella config is what should be used instead of config in each sub-project). And lastly, a single deployment. It’s the last part that is usually the focus of umbrellas in most people’s minds because that’s what you end up with. The side effects are that the umbrella is typically managed as a single GIT repo, and while submodules could be used, they bring complexities of their own. In addition, if you have utility modules that might be used in many app deployments they don’t belong in an umbrella but as a separate dep. Conversely, if you want to have a few different app deployments with differing mixes of projects, a single umbrella can make that more complex as well.
I’ve stopped using umbrella projects. I have a single directory with deps between projects: path: “…/another_project”. This has effects in the work flow as well, and you have to consider where config lives. But then each project has its own GIT repo, and deployment is centered around the projects that provide the service (an api module would include the necessary deps and would be the thing that gets deployed).
I have more specific adaptations to using this flat multi-project layout, which I intend to document and release as template/tools in the hopefully not too distant future.
As I was reading your response I was thinking “please please have a an article or repo to show what you mean”. Since I am new your description seems really interesting but I cannot visualize exactly how things are structured. Whenever you get a chance to write a blog post or push a template to github please do share.
