A better solution is to just be unafraid to make top level namespaces in the main app (like how Phoenix creates MyApp and MyAppWeb)
That was a game changer for me.
Also realizing that my team doesn’t want true microservices. We simply want individually scalable deployments, but on a shared codebase.
Yep, this is like the ideal use for them in my opinion. Good for code/config re-use between strongly related projects that have more than one deployable build target, and different resource/scaling needs.
Precisely this!
There’s the further issue that you also have to conditionally configure other dependencies, like Ecto pool sizes, depending on the target environment. This is something you could get clever with using Mix.target for, but it still permutes your config access at every point it is used.
I was trying to remember why I used to get frustrated working on one app I had, that was an umbrella app.
More directories can be a pain to navigate, especially if you are using a navigation tree. Having to be in different directories perform different mix tasks can also be a bit of a headache.
This was why. I was working on was a web application, that had one app for the Ecto/context layer and one for the Phoenix/GraphQL API - and it drove me nuts needing to constantly swap between folders to run different mix tasks.
it drove me nuts needing to constantly swap between folders to run different mix tasks
Unless it’s a one-off, I’m always using mix aliases at root with mix cmd to target apps:
[
"my_task": "cmd --app app_1 mix my_task"
]
Interresting. Another solution is to have multiple tabs opened in the terminal and just have each of them pointed to the folder of a different app of the umbrella project.
I do similar setup for my code editor. Multiple workspaces for the same umbrella project. Depending on which app I want to work on, I just switch between the workspaces.
IIRC, mix commands run at the toplevel in umbrella apps “federate” into all subapps. So calling mix test will invoke it on all of them that have it defined. I’m not sure if it recognizes aliases within subapps, though—if not, you’d want to duplicate the aliases like described, and I think that honoring aliases would make a great feature request
IIRC, mix commands run at the toplevel in umbrella apps “federate” into all subapps.
Unfortunately that’s not how it works. The mix task in the dependency have to understand umbrella structure like how ExUnit handles it for that to work. So it depends on the dependency.
The default generated umbrella phoenix app will have a setup alias in each app and one at root level calling it recursively for each app using the cmd task.
i share that umbrella apps can be tricky for maintenance and operation
but, what about umbrella apps from perspective of tests?
example:
api → core → store
rpc → core
cd api; mix test → verify from api to store and not know rpc
cd core; mix test → verify from core to store
From perspective of test we run “isolate” from other apps , so this allows us to partially verify the hierarchy.
At least, for my team and i, allows to easy locate and test behaviors of the system.
I’m curious how people are using umbrella projects these days.
I recently discovered that usage_rules doesn’t work out of the box with umbrella projects, so I started looking into a fix. Even just getting a list of all child projects wasn’t as straightforward as I expected.
It got me wondering: is the Elixir language and ecosystem gradually moving away from supporting umbrellas, either intentionally or just in practice? What are your thoughts?
