Newbie here (and to Elixir/Phoenix), so take with a grain of salt.
Unless I’m mistaken, in hard technical terms, I’m not sure I see a hard delimiter.
I don’t think anyone is saying there is a hard delimiter? Communication of intent is a huge part of software engineering. An umbrella project communicates (and reifies) the concept of “these are all part of the thing we are building, but they have been separated at the application level for reasons x, y, and z”.
So yes, granular code organization is nice, but the complexity is [edit: sometimes] warranted for this and reasons mentioned by others above.
3 Likes
Except that it doesn’t “reify” anything. It provides no mechanism to do that. So if all we want to do is communicate intent, why not use module structure to do that? And leave apps for what they were originally designed for: packaging dependencies that have a separate deployment lifecycle from the main application.
Good point. I was thinking in terms of the umbrella giving you said module structure. In that sense, the utility is perhaps more pedagogical than prescriptive, with the additional benefit of being able to run mix tasks from the root (umbrella) project—which is very practical.
And leave apps for what they were originally designed for
Well, the umbrella is not really an Elixir app per se, if that’s what you meant. I’m also not sure in which situations it would make sense to add dependencies to the umbrella mix project itself, since those deps aren’t available to the inner apps.
Or are you suggesting an alternative to creating an umbrella project is to create an actual umbrella-like app?
In any case, as the Elixir guide says, you don’t have to drink the Kool-aid. Your mileage may vary, it depends, you do you, etc.
Right. If you are actually building a single application, such as a web application - I would use the module hierarchy to delimit separate logical concerns and give umbrellas a miss completely. I believe umbrellas have a place, but it is for managing multiple libraries in a mono-repo. If you actually are developing and releasing (even if its a private release) your own libraries as part of your application, then umbrellas are a great fit. But they don’t provide anything beyond the module system in terms of segmenting concerns in a single application.
1 Like
But in an umbrella, if you make circular dependencies or use modules that are not correctly required, it will bail out on you when building the release (although not when running it in mix), and this forces you to not have circular dependencies and having the correct deps tree structure in your app? So it might provide you with a better insight into the decomposability of your app down the line?
2 Likes
If thats the case then I’d agree, it is providing a real mechanism as long as you use distillery. Thanks for finally cluing me into that.
1 Like
