I would appreciate advice on the best practice for organizing several interconnected Elixir apps. I suspect that what I need is an umbrella project, but I would like to confirm this with the community.
I have three apps (1 is in active development, 3 I’m just starting, 2 is planned):
A command-line app with a database that I plan to distribute in binary form to customers
A premium app that implements additional functionality and a web UI
An internal app (development and debugging tools, also with a web UI)
Based on my understanding of umbrella projects, this would be the right solution if implemented like this:
my_umbrella
apps/my_app # command-line app
apps/my_app_web # web UI + premium features
apps/my_dev_app # internal development tools
In this scenario, my_app_web and my_dev_app will both have my_app as a dependency, giving them access to all the core functionality, Ash resources, and database access. At the same time, I can distribute the first two apps separately, while the third internal app will never be distributed outside our team.
Is this the right approach? Are there any things I should be aware of, or is everything fairly straightforward as described in the official docs?
Umbrella apps are intended to be distributed as a unit. I would not recommend an umbrella app for this purpose. I’m under the impression that umbrella apps get loaded all together, and that references can creep into apps under the same umbrella in ways that those references can’t if they are in independent projects.
If my_dev_app is not intended to be distributed with my_app & my_app_web, then I would strongly recommend that it is kept separate.
I have been a part of several large umbrella projects, and In general I have found over time that all of these projects generally get flattened - and if not fully turned into individual projects, that the core components get merged into a single project, and that only other apps in the umbrella are custom libraries that are under active development.
I wish we could remove this misunderstanding about umbrella projects (not apps). One umbrella project can map to N releases. Releases are the deployment unit. The umbrella represents a way to organize the code “at rest” on the filesystem before releases are built.
If they’re not intended to be distributed together then the two (or more) release definitions should not include them both.