Best practices: Umbrella app with Multiple Repos

This seems like a bad idea for umbrellas. Umbrellas are one app. They are. They are not one repo with multiple different apps. They are one app with multiple concerns. They are one app.

Do you want to feel deploy them as one or make seperate deployments? If that’s so, I think what you are looking at is poncho apps. Since they are their own report, I think you should move away from umbrellas and move into poncho.

As per the DB, this means memory usage will increase for each new app. If that’s ok, go for it. The amount of connections will be dependent on what each app requires. Normally I just worry about that later when load increases, but only if this current config can sustain the current load.

Hmmm… I’ve never heard of poncho apps and have only found 1 rather cursory post about them.

I agree that what you describe sounds more like poncho projects, which was pioneered by the Nerves team and also something Dave Thomas has used with his component-focused approach. The original writeup I’m familiar with is here https://embedded-elixir.com/post/2017-05-19-poncho-projects/

In my understanding I make a distinction between apps and projects. Projects are how code at rest (on the filesystem) are organized. Apps (in the OTP sense) are a runtime concern – basically a branch of a supervision tree. You can have a 1-to-1 mapping of project to app, or a 1-to-many. Umbrellas are projects with a 1-to-many mapping to apps. Things get more flexible when you also start thinking about releases. Releases are deployable units of apps. You can have multiple releases out of one umbrella, each using some subset of the contained apps. Distillery supports multiple release targets specifically for this purpose.

I like umbrellas. They fit well with the type of app I’m familiar with. I make one mitigating change from default umbrella setup to run each app’s tests in a separate BEAM to suss out any improper coupling early. Umbrellas may not fit everyone, but I’ve also heard a lot of misinformation.

This isn’t true at all. Umbrella contain separate applications, and while sometimes these depends on each other it is not hard requirement and you can easily deploy them independently from each other.

Ponchos are just different form of keeping projects in the same repository. Nothing prevents you from using Poncho like Umbrella structure and vice versa (ok, using :in_umbrella will be harder, but that isn’t much of the problem).

You do not need Umbrella for that. Nothing prevents you from having multiple repos in the same application.

We cannot answer you to that question, as this highly depends. In your case you are very limited by the number of the connections, so you have your answer. In bigger systems? Who knows, sometimes it can be solution and sometimes it will not be.

Interesting thoughts – this has given me a couple ideas of things to try, so thank you!

Unfortunately, the idea of the poncho app is currently too vague to be useful to me. From that one short post, I have no point of reference having never built a nerves app or built firmware etc. If someone could write up something more thorough demonstrating where a poncho might work vs. where an umbrella would not, that would be something…

Yes, you can. I used to think this for a while as well. But umbrellas are meant to be their own application. Deploying individual apps with umbrellas is possible. However, they are one app.

I would like you to set up an umbrella app, install Phoenix 1.4, then install another app with Phoenix 1.3. You’ll get dependency conflicts. For more complex umbrella applications, this has been a major problem for moving certain apps forward since you’re forced to do a project-wide update instead of being able to update each app individually.

The idea of a poncho app is really simple. It’s just like an umbrella app but instead of a single OTP app ruling everything, you have mulitple mix.lock files instead of a single mix.lock that can cause issues.

I think the big thing is with dependencies. At my current company, we’re using umbrellas to have very separate apps and deploying them individually. When we went to install Phoenix 1.4 into another app, we were blocked because we had another app that was stuck on Phoenix 1.3. I soon learned that this is what Poncho apps were meant for, not Umbrellas as highlighted by the Slack channel.

I’m not sure what it takes to convert an umbrella to a poncho, but instead of doing in_umbrella: true, you instead just specify a path.

You keep emphasizing that, but I cannot agree. Yes, they must have a consistent set of dependencies, and they have a mix.exs file, but that is not sufficient to make them an OTP application. Their mix file is lacking an application configuration. They have no Application behaviour module and no supervision tree. Umbrellas are best thought of as a “project” of shared configuration and dependencies.

That’s what I thought too but it was very much explained in the slack that they are just a single app and people should be using ponchos.

This is where you lost me. If all these “Repos” are using the same Postgres instance, I’m skeptical there should be multiple Repos at all. Your apps can depend on each other, so you could have a shared Repo app that is used by all the different components, and yet each of those can have their own schemas, which may overlap or not depending on your architecture.