ream88

Best Way to Structure Two Similar but Separate Phoenix Apps?

I have developed a management app and now want to create a separate front-end app that interacts with the same data. This new app needs to remain lightweight, avoiding unnecessary dependencies and assets. I’m currently facing challenges with:

Separation: Keeping the apps independent while avoiding duplicated configurations, such as Tailwind and custom Plugs.
Code Reuse: Preventing dependencies and logic from becoming out of sync or duplicated.
Maintainability: Striking the right balance between separation and shared code.

I’ve tried umbrella apps, a single app with multiple endpoints, and fully separated apps. However, each approach has trade-offs—either too much coupling or too much duplication. I still struggle with keeping shared logic in sync while maintaining separation.

Would love to hear how others have tackled this. And yes, I know I asked a similar question before… Sharing code across apps Pretty sure ChatGPT just reused my own question. Thanks!

5 comments

/phoenix #umbrella #project-structure

0 340 5

2025-03-22 09:49:39 UTC

Marked As Solved

ream88

I think I might have found a way that is feasible and also allows me to share most of the code base (including assets). I started using a custom ENV to change what routes are compiled and which processes are started. And after I got this working, I remembered that Nerves is using MIX_TARGET for configuring and compiling different apps out of one code base. It looks promising and I’m nearly done, maybe I will write a blog post once I got it working completely!

Post #6

Also Liked

garrison

This is totally subjective and contextual. Personally when I hear “separate frontend for the same data” I think you should keep it all in the same codebase. You can always make it look to end users like it’s a different app (serve it from a different domain off the same server).

But there are some cases where that’s not true. For example if you want an “open source” part and a “proprietary” part like, say, Oban Pro.

Post #3

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

Hey @ream88 to me these sorts of questions are best answered by looking at the people who are developing on them, rather than focusing on the “best” answer from a purely technical perspective. Specifically, I think you should structure the code in a way that mirrors who is ultimately responsible for each function.

If you have two distinct teams (even small teams of 1) and it’s common for features that you build for the user facing app to have 0 impact or require 0 changes to the backend app, then two distinct apps with perhaps some extracted functionality can work.

If however you have just a single team (or individual even) who is doing both, or features / PRs that you do for one often require a “paired” PR in the other, I would definitely do just a single application and use the Boundary — boundary v0.10.4 library to help delineate groups of functionality within the application.

Post #2