@egze so, it is something like the Facade pattern? Or am I missing something?
Fl4m3Ph03n1x
egze
I guess. Never thought of it in terms of patterns.
I took this approach from this blog post https://medium.com/onfido-tech/the-not-so-magic-tricks-of-testing-in-elixir-2-2-acdd0368572b
See part about “Don’t mock what you don’t own”. In the context of app, we don’t own api_client, so we make a wrapper for it.
2
slashdotdash
@Fire-Dragon-DoL Have you seen the approach outlined in Application Layering - A Pattern for Extensible Elixir Application Design?
I have used a similar design where a behaviour is defined for each Umbrella app’s public API module and the implementation module is configured via the Mix environment. For :dev and :prod it uses the default implementation, for :test it uses a Mox mock.
This allows the tests within one app to stub responses for calls to any other app. You can also use Mox’s stub_with/2 function to forward calls to the mock on to the actual implementation if necessary. This can be a useful approach where you can mock some calls, but allow other calls to be handled as normal.
0
Fire-Dragon-DoL
@slashdotdash I’m guessing this was meant for the OP?
Although it’s interesting that it comes from you, since I think the entirety of these problems disappear when you use event sourcing 
0
Fl4m3Ph03n1x
After reading through this discussion I realized I had a circular dependency issue, which I have now fixed with the knowledge gained from reading this thread.
Thank everyone!
The solution I opted to go with was to use create a behaviour in the manager module that exposes its Public API and then import it in the applications that need it.
This does bring up another question, but other than that, I’m all good 
0
WFransen
Hello, not sure if it helps but have you looked at GitHub - sasa1977/boundary: Manage and restrain cross-module dependencies in Elixir projects · GitHub ?
Personally I’d be really happy if something similar could be introduced in Elixir apps (either from an umbrella app perspective / dependencies perspective).
0
Fl4m3Ph03n1x
@WFransen An overall interesting idea that forces you to think about your project in a different way. I believe this is not needed for more experienced developers, but for teams that are new to projects or that change constantly I believe it to be quite a nice tool.
In my specific case, it wouldn’t help much, but I see the value in it.
1