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)}")
end
end
# 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
# ...
end
end
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)
end
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.
