axelson
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?
Marked As Solved
benwilson512
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.
Also Liked
OvermindDL1
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.
OvermindDL1
Yep! This is what I was proposing! Thanks for the specific example, I’m in a bit of a rush this afternoon. ^.^
axelson
@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!
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"