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

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.

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!