Sharing code across apps

We’ve done someting like this at work with a Ruby app. We used a git submodule for the common parts, but eventually realized that we were basically reimplementing a package manager using git.

If I was to do this again, I would first seriously consider keeping everything as one application. If that got ruled out, I would probably make a regular library from the common code, so that it would be managed the same way as all other libraries.

But then it’s important to be very careful about what this common code depends on. Our apps share some dependencies that are really only needed by one of them, but the submodule was pulled out ad hoc without anyone puting in the effort to really make it reusable, so it’s kind of a mess.

I don’t know if you want to introduce complexity from git into your codebase, I personally wouldn’t consider this as a viable option.

Depending on how your projects are organized, I would recommend to have the shared code separated in a library, but in the same repo (a monorepo that hosts both the projects and the library). In this way you can use the option of local dependency and not worry about maintaining separate variants for the library codebase and version them:

defp deps do
  [
    {:local_dependency, path: "path/to/local_dependency"}
  ]
end

If you must split it off, then +1 to path dependencies in a monorepo. You would end up with applications like app, app_back_office, app_common and app_web_common. Check out [workspace] for working with a monorepo.

Monorepo with different applications – not an umbrella. And path dependencies.

Though I’m curious why making a library out of the common code is not an option.

TBH I don’t understand the anti-umbrella vibes; the alternatives suggested all sound like umbrellas with extra steps

You are more regular here than me, you are telling me you don’t remember the objective arguments against them?

TBF I don’t remember them but I’ve tried umbrellas, the whole package, from ideation to deployment and they had drawbacks I was not willing to live with. And other people expressed the same and made lists. I did not save those lists but again, there were good reasons.

Though in this case of this thread in particular, I don’t get the anti-library sentiment more.

From the experience I’ve had, umbrella projects bring in more problems than they solve. Starting from configuration handling to OOM issues when fetching dependencies for multiple umbrella projects.

The idea of umbrella projects is to have separated OTP apps and that is a hard requirement only for a very few specific projects.

More like “didn’t particularly pay attention to”. You can find folks who’ll decry the use of ANYTHING - even if statements! - and I wasted waaaaaaay too much time arguing with that sort in Rails-land.

I’ve seen an umbrella solve OP’s specific problem very efficiently - the system was one that coordinated delivery companies (+ drivers) and stores. The key problem the umbrella solved was keeping UIs for different audiences entirely separated; apps were roughly like:

• core: giant ball of DB schemas + business logic
• store_web: UI for stores to use to submit & track delivery requests
• driver_web: UI for drivers to use when making deliveries. Mobile-first, designed to tolerate drivers losing network connectivity intermittenttly
• dispatcher_web: UI for the dispatchers to manage their driver’s work and check status

We didn’t do anything fancy for deployment like splitting subparts (for instance, deploying core + store_web separately) but the built-in boundary checking means we could.

This setup really showed its benefit when Bigco asked us for a new interface that would let Bigco management admin all of their stores. It found a straightforward home as a new bigco_admin_web, with a separate asset pipeline so BigCo could have their logo plastered on everything.

Another nice momement was when we needed to add SAML as a login option, but only for stores. This involved “splitting” the login form to ask for email first, and then either prompt for password or redirect to the IdP. Since each audience has its own _web, it was straightforward to modify only the one for stores.

None of these are strictly “only umbrella could do this”; a team with sufficient organization and discipline could accomplish the same thing all wedged into one Phoenix app, the same way a team like that could make a well-factored Rails monolith. Here in the real world, IMO the umbrella helped us keep things organized despite the hectic schedule of a startup.

I think I need to provide more information. My goal was to find a quick and easy way to test if a back office app is feasible. I planned to launch it on fly.io without a public IP, making it accessible only via Wireguard. In the past, I’ve worked with various solutions you mentioned: monorepos, umbrella apps, and shared libraries. However, none of these solutions are simple enough for a quick Sunday afternoon hackathon. They all require structuring the code in a way that feels like premature optimization. And it is mind-boggling to me that something so simple is this hard in Elixir.

I currently have a proof of concept running with this in my mix.exs: {:app, github: "repo/app", sparse: "lib/shared", app: false, compile: false}. Then, I run Code.compile_file("deps/app/lib/shared/file.ex") to make it available.

If you want a quick and dirty way, can’t you just add an option to your main app to not start the application tree and just use it as a library from the thing you are currently building?