Best practice for calling a function in another application without defining a dependency

I am working on an application that is structured as an umbrella application. Currently there are only two applications in the umbrella, one really small application and one that is quite large/monolithic Phoenix app that we are in the process of breaking up into multiple apps.

Is there a best practice for calling from one application to another without defining a direct dependency between the two?

The reason that I want to do this is that I want to avoid a circular dependency among the applications, but I still want app B to be able to notify app A that a particular event has occurred (i.e. app B does not need to receive a response). I believe I could do this by utilizing Phoenix Pubsub but I am wary of relying too heavily on that approach because in my experience it can cause “action at a distance” type of problems or otherwise make control flow hard to follow, especially if a subscriber then publishes another event.

Am I barking up the wrong tree? Should I use something like GenServer.cast to notify app A from app B?

A bit off-topic, but instead of phoenix’s pubsub, you can create a local pubsub out of Registry, make it your third app under “umbrella”, and communicate inside the node through it. That’s what I do, but “action at a distance” is definitely a problem.

To alleviate it to some extent, you can declare macros (or functions) that return topic names for every possible subscription inside a single place (local pubsub, for example).

defmodule PubSub.Topics do
  # not sure if it compiles
  defmacro subject_update(subject_id) do
    quote(do: "subject_update:#{unquote(subject_id)}")

# and then in other apps
require PubSub.Topics
PubSub.publish(PubSub.Topics.subject_update(subject_id), %Subject.Update{...})

or maybe go even further and define a pubsub submodule for any possible communication

defmodule PubSub.Subject do
  def publish_update(...) do 
    # ...

What I do and have always done going back to erlang days (though with Elixir you can macro-inline calls) is thus:

Define my behaviours in a base library, depend on it (I may have multiple behaviours in multiple dependencies even). In the Application.get_env stuff (settable from Elixir via config.exs) get which module is being used if it can be backed in, if it is more ‘flowing’ and not baked in then pass the module name as an argument through the calls. This also make it really easy to swap out implementations as you need, including one specific for tests and more too.

I don’t really use umbrella’s though, but rather have each application be a dependency of an overall main application that otherwise does nothing but set up all the links between them.


I think so. I mean if A depends on B, but B can call A’s code, then B also depends on A and you’ve got a circular dependency whether you’ve written it down in mix.exs or not.

Phoenix.PubSub is both a bit heavy weight, and also I think the wrong paradigm. What you need are event handlers, which can happen with basically just pure data, the process based subscription model of Phoenix.PubSub doesn’t make sense here. Simple version basically just does the following.

Have A configure b with an event handler module found in A:

# in app A's config

config :b, event_handlers: [SomeModuleInA]

Then in B, instead of calling A’s code, grab event handlers and call a function:

for handler <- Application.get_env(:b, :event_handlers) do
  handler.dispatch(:foo_created, some_data)

We’ve done this in our umbrella apps and it’s worked pretty nicely. It avoids a circular dependency, while still avoiding a “broadcast to the winds and who knows who responds” kind of situation, since it’s pretty easy to keep track of the handlers list.


Yep! This is what I was proposing! Thanks for the specific example, I’m in a bit of a rush this afternoon. ^.^


@benwilson512 thanks! That approach looks pretty neat. I think I’ll try to combine it with a shared behaviour as well.

Also I’ll probably tweak the config so that multiple applications can register a handler. So there will be lines like

# in apps/a/config/config.exs
config :b, :event_handlers, [a: [SomeModuleInA]]

# in apps/c/config/config.exs
config :b, :event_handlers, [c: [SomeModuleInC]]

Thanks for the suggestions!

1 Like