Same here. Whether you use an umbrella or separate apps + path dependencies makes very little difference. A mono-repo however saves you a lot of code management work like git submodules or having to run same script commands 5 times in a row (I’ve seen people argue that you can do your own scripts that do that for you but this makes onboarding a bit harder, and makes the junior devs believe in magic which is highly undesirable).

As for apps vs. libraries – if any piece of code has any “active” parts (like firing background jobs or updating internal cache from a SaaS source or global database), then it must be an app; if it can be entirely passive and is only called when needed, it should be a library. If you can open-source it, even better.

I see umbrellas mostly as a tool for code organization. You have a number of coupled OTP applications and you want to make version control and version management easier and hence use an umbrella mono-repo.

I feel the question you are asking is rather how to split work up between different OTP applications. If they are part of an umbrella or stand-alone dependencies make very little difference.

The questions you need to ask:

• Do you want a separate OTP application with its own supervision tree? Then you must make it an OTP application. This is about how you want your application to fail. For example, are you OK with an application dying but want the rest of the system to keep going? Then use a stand-alone application. Do you want your application to fail if it fails? Then either depend on the application or move its supervision tree into your supervision tree (either though included applications or just by starting its supervisor in your tree)
• Is the OTP application coupled with the rest of the application? I.e it is only going to be used for this particular application? Then I believe a mono-repo makes life easier but more from an SCM point of view rather than being an elixir problem.
• Can the OTP application be re-used in a different application? Then it should be a stand-alone application and not part of an umbrella.

I’ve used umbrella apps to decompose a large web API. One main app defined the Endpoint and common Plug pipeline, then forwarded to child apps.

Each child app exposed a Router and defined a test-only Endpoint. We’d typically CD into an app directory while working on it, then run the whole project test suite before pushing to git.

All apps shared a single data warehouse, so the Repo and shared Schemas were defined in a shared app.

The shared DB architecture made it a good fit for the umbrella project. We could apply migrations and test that all apps depending on those tables were still working.

For a new project I’d like to try apps for web, cron, jobs and core logic.