Questions about Umbrella apps

Yes

That is the usual workflow in my experience

Yes, two separate apps would listen on two separate ports. There is some endpoint trickery you can do to allow them to share the same port, but the default would be like you suggested. So your Admin Web will listen on different port than Store Web, which might be good thing.

Yes, the whole runtime including processes and modules and all the code is shared. It all runs on the same VM if you use single node and do not do any clustering just yet, and communicates using function calls and local message passing (i.e. call/cast).

In your Repo app.

Most of your technical questions have already been answered but I feel the need to point out that the breakdown you showed might be a bit too micro (that depends on your needs of course). What I usually do is to have:

• data app, contains all data structures and all storage mechanisms’ drivers (PostgreSQL, Mnesia, Riak, Redis, Cassandra, what have you). Only schemata and migrations here, zero business logic if possible.
• domain app, or, lately I started naming that app with the name of the business itself. Contains every single piece of functionality to make your web app or API work – like the Phoenix contexts, more or less. Stuff like User.forgot_password or Cart.add_line_item or Order.finalize or Customers.send_marketing_emails goes here. It’s also a good idea to include your backend-agnostic authentication and authorization logic here, or, if that proves to be too big, refactor it out in a separate app (so far I found that to be an overkill though).
• web app, where I put everything needed for the website (or websites) of the business (Phoenix, Plug). Uses the functions in the domain app heavily, has no idea about the data storage mechanism at all. Should use functions like Cart.delete or Accounts.confirm_registration that change the database below and must never ever use a single Ecto-specific function or module (or whatever direct storage library). Might include authentication / authorization modules, as long as they are specific for the websites only.
• api app, where everything that exposes REST or GraphQL endpoints lives. Same as above: uses the domain app heavily, must have no idea about the data storage mechanism. API-specific authentication / authorization modules included.
• Lately I started adding another one in my projects: reports. Reports are a very weird beast and more often than not it’s best if they are just stored SQL procedures but when that’s not possible (namely when no dev wants to get their hands dirty) it pays really well to have all the ugly compromises and flaky performance optimizations in an entirely separate app so you can change stuff around without affecting your business logic or anything else.

One important caveat though: when using Ecto – like most projects do – having business logic wrapped in changeset functions is very valuable. Code like this:

params
|> cast(:your_association)
|> validate_required(...)
|> ensure_enough_stock(...)
|> apply_discounts(...)

…is very intuitive and the pipe-able nature of the changeset functions that usually live in your Ecto schema files makes validation and any extra requirements and data reshaping very convenient. In the end I left only validation in these (and they have to 100% mirror any database-level constraints which are encoded in the migrations; such duplication is one of the very few flaws of using Ecto) and moved the extra checks and processing into the business logic app – and I am calling them directly from the Ecto schema file changeset function.

That’s kind of ugly and creates a mutual dependency but so far hasn’t been an issue and still gives you a pretty strict separation of concerns.

In general: don’t let frameworks shape the project’s file structure for you. Think for yourself what makes sense, which apps/modules should be mutually dependent, which should be black boxes to the apps/modules that use them, and make the call. Elixir isn’t conservative in this regard; Phoenix just gives you sensible and easy to work with defaults but they are by no means mandatory. Trust in your own judgement!

My $0.02.

Thanks. Would it not make more sense for the schemas to live in the app (or context if you will, as is the case with Phoenix 1.3)?

I maybe wrong, but reading your reply makes me a little apprehensive. It seems like added complexity, and in my mind it makes reasoning about the app difficult, but of course I’ve never seen your code or worked on your app, so I might have the wrong impression.

Thank you.

In your Repo app.

The schemas would be in the app, though?

I put them in the repo/db app. But I don’t generally put a business logic in them either.

I put them in the repo/db app. But I don’t generally put a business logic in them either.

I take that to mean that you’re changeset functions also live in the app or context?

I am brand new to Elixir and haven’t even started learning Phoenix yet.
I just read about Umbrella Apps yesterday and like the idea of dividing an App by ‘context’ to prevent creating one big, messy, monolithic app.

Simple question: Can one ‘sub-app’ easily inter-communicate with another ‘sub-app’ (i.e. sub-app A gets information from sub-app B and stores information to sub-app C)?

Yes. See in Dependencies and umbrella projects:

defp deps do
  [{:kv, in_umbrella: true}]
end

…in mix.exs should be enough.

Yes but note that should only be calling in one direction. So B can depend on and call methods from C, but C cannot depend on or call methods from B. There are ways around it (such as registering a listener), but generally you want to have just one-way dependencies.

Thanks dimitarvp and axelson! Much appreciated