A question about architecture, phoenix contexts and why bytepack chose an umbrella design

I’m sure most of you have all seen https://github.com/dashbitco/bytepack_archive
Thank you, honestly this is a great learning resource. :pray:

One of the first things that I noticed was it was an umbrella app.

I’m trying to reason about the logic behind the app structure.

If you are using a flat phoenix app (ie non umbrella) you would basically have the same design but abstracted at the context.

Whereas the umbrella app for bytepack does that abstraction all the way at the app level.

Is there a strong case for defaulting apps to always be umbrella apps like bytepack from the start?

For example, I don’t necessarily see (though I have not fully read the code), how bytepack being an umbrella app like this was more beneficial than just being a flat phoenix app. Now I get that whole your app is not a phoenix app. Regardless I’m left wondering if I should just forgo building flat phoenix apps and always just start as an umbrella even if the only abstraction is phoenix.

Also a question about scaling. I’m assuming this pattern favors scaling only the app thats requiring it.


I will say there is at least one downside to building an umbrella app – you can’t host the docs on hexdocs yet =(.

Honestly, we simply chose umbrella for this project so we could try it in anger and see if there is anything we could contribute back and improve. One direct consequence is that we did make the compiler smarter about umbrellas alongside other improvements on the recently released Elixir v1.11.


:rofl: you’ve been hanging out with Dave Thomas again, haven’t you?

All jokes aside, thank you again for sharing bytepack

One benefit I’ve enjoyed is a separation of concerns with regard to the “applications” view in :observer. There’s a clear delineation between the applications, and I find I’m more easily able to locate the process I’m looking for.

Whereas a “flat” phoenix app displays the entire process hierarchy in a single pane.