vkryukov
Hi,
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?
Many thanks!
Victor
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
At WyeWorks, we believe great software is built by combining technical excellence with genuine human connection
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
al2o3cr
Seems like a good use case - the compiler will ensure that no references to code in
my_dev_appsneak into the other two.jeremy.owensboggs
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.
gregvaughn
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.