Writing modular / composable phoenix code

AFAIK there is no support for this out of the box but it should be doable.

Assuming you really want to have multiple Phoenix apps, then going down the umbrella app route is most likely the best approach.

For that you would have one “main” app, and a number of “sub” apps (just by name though, from the umbrella perspective they are all equal).

Your “main” app would then depend on all these “sub” apps and actually serve requests. In the main apps router you could then use forward to forward the request to the router of the correct “sub” app. From here on it’s business as usual.

In the “sub” apps you would merely disable the server option of the Phoenix endpoint (in the config, the default is false), so that they do not bind to a port.

If you then at any point in the future want to extract a “sub” app into a standalone app you would have to set the server option back to true (and of course clean up the umbrella stuff, there are guides for this).

Does this help you?

Thank you very much for your detailed answer @wolf4earth! It is a good starting point for me and I will definitely attempt it.

Do you think it will be ok to make associations between models as needed, even though they live in different umbrella apps? For example, the “main” app will have a user model, and a “sub app” a blog post model. These have to be associated with one another (user is author of a post).

Also, why is this not a frequently asked question? Do other people just write their apps from scratch?

I have re-used modules many times from different Phoenix projects: they are very portable. The only wiring that was needed to install them was to reference them somewhere (e.g. in a plug or a controller). It’s not a plug-and-play as, say, a WordPress plugin, but 1 size doesn’t always fit all. Sometimes the “simplicity” in having things as easy to install as a WordPress plugin backfires when you need to customize it, and jail-breaking the functionality out of its carefully defined environment is harder than just wiring in more generic modules.

Phoenix Plugs might be the middle ground there: they revolve around a well-documented struct and are easy enough to reference in various projects. They can be used to handle an entire request, from soup to nuts, so I would recommend giving them a look before trying to balance multiple Phoenix apps under an umbrella or some other more sophisticated solution.

I don’t think it a good idea, given your requirements that apps are self-contained. What you are proposing definitely breaks it.

What you need is sort of micro-service design. There is an accounts application. It is concerned with users and everything related. It also publishes changes (PubSub, AMQP, whatever).

Blog application deals with blogs and posts. But since it needs users also, it subscribes to the messages from the Accounts app and keeps a local copy of users table. But their DBs and tables are not touching each other. Each app has its own.

This is only a quick idea, there are more ways how to build such a thing. But it is a good amount of work to set it up properly. I’d only do this if working in a company where each team implements their own service.

Thanks @egze. So if I understand correctly, its best to implement microservices revolving around core datastructures that can subscribe to one another, but only in the case where you write a suite of apps that will use these services. Otherwise for individual apps, write it from scratch?

Yeah, I would not bother with such strict boundaries for a simple application.

Btw, have a look at this video: https://www.youtube.com/watch?v=hgDCg3QdZgU

Thank you very much. I will certainly check it out.