How much do you split up your umbrella application database dependencies?

We made the switch to an umbrella app recently to keep projects with like-dependencies together, but as a result, I’ve had to start thinking about which projects do and don’t need to share database dependencies.

For instance, we have a set of common modules that form a pipeline, but only certain steps in the pipeline require DB connections (i.e. some modules don’t need the db at all but share non-DB-centric code with the others).

At a certain point, the logical thing to do in an umbrella app looks like splitting up the modules into smaller and smaller apps to granularly control which apps depend on which DB connection and which don’t so as to only be supervising connections when absolutely necessary.

I’m not super-worried about connections, I’m mostly just wondering what everyone is doing with their umbrella apps with respect to compartmentalizing DB awareness: how small do the apps in your umbrella get?

2 Likes

I tend to go for standalone applications. This makes it easier to:

  1. include them in another umbrella
  2. upgrade them individually

Standalone would mean I’m able to git clone that one app, mix do deps.get, compile, ecto.create, ecto.migrate, run end and it would magically work.

If there are common elements I would abstract those into a library application or deps.

Tend to also means I have broken this guideline before. Especially if the application will never exists by itself and itsn’t a purely library application.

YMMV.

1 Like

In the one case where I had an umbrella app with a database connection, what I did was put all the database functionality into one application in the umbrella and the used that application’s interface to handle DB interaction from the other applications in the umbrella.

To think of it another way, I implemented a library that presented the persistence model for may solution and everywhere I need to do persistence I called that library. In OTP parlance the library had the rather unfortunate-and-severly-overloaded appellation of application, but it was really just a fully modeled library for handling persistence in my problem space.

(and the entire solution in question was very small. I don’t have experience with how well this would scale so caveat emptor)