magosi

Writing modular / composable phoenix code

Hi, my current Phoenix project involves a website with a lot of different functionality, like a digital store, chat system, file uploads, blog posts, comments, etc. How can I go about developing this project so that each feature is a self-contained unit that I can reuse in future projects? For example, how can I make the digital store (with its contexts, views, templates, routes, etc) a unit that can plug into the project and plug into future projects? I know Django has a concept called apps that serves this purpose. Does Phoenix have a similar feature? I have seen people mention umbrella projects and I have made a small umbrella project before when I read the book “Programming Phoenix”, but I am not sure how to go about splitting these features so that they are almost pluggable. Any advice is appreciated and I would like to know how some of the more experienced Phoenix developers reuse code between projects to avoid reimplementing functionality.

7 comments

/phoenix #umbrella #dry #software-design

0 1387 7

2020-04-27 16:16:59 UTC

Most Liked

wolf4earth

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?

Post #2

fireproofsocks

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.

Post #4