Avoiding circular dependencies between 2 umbrella Phoenix applications using each other's routers

Phoenix Forum Questions / Help
, ,
1

So I have the umbrella project that consists of user_interface and admin applications. I want to display some links from user_interface back to appropriate admin panel section when logged in user is admin. And I also want to display links to public facing URLs in user_interface, from within admin_panel.

As you can guess I am creating circular dependency here. One application has to be compiled before the other, so I think I need to decouple these.

As far as I see it, I have the options to:

  • move the routes resolution to runtime. I think either exposing GenServers with registered names on each end that expose underlying router functions will do, or I an use :erlang.apply
  • use dependency injection where I would figure out the appropriate router module at run time
  • hardcode the URLs :wink:

Any other ideas? What do you think would be best?

1 Like
2

Well, there’s also option to just use module names / functions directly, just can’t import them. So I need to make remote call, directly using module names of the other apps. There is no compile-time check for safety, and compiler gives you warning, but that’s probably fine - none of the other solutions give compile time safety either. But I think its the best and simplest. I’ll go with that. Leaving this thread here so it’s helpful for someone in future :slight_smile:

3

I’m not sure that this is the right way to go. Part of the idea of an application is that it can be run independently without anything other than items on its dependency list. If you try to run your admin panel without the user_interface happening to be there it’s going to crash.

4

Which is still good I think. Even if user_interface is not running, if I do:

MyApp.UserInterface.Router.Helpers.some_path()

It will still work as long as the other app is compiled at some point and function exists/matches arity etc. The only problem I see is that compiler will not detect invalid function calls. I.e. I rearrange routes in user interface and my admin interface will crash.

Well I don’t know, it looks like stupid question but surprisingly tough one.

5

It’s this assumption that is the issue. Build a release with just your admin app in it. It’s only going to have the admin app and the code from the admin apps dependencies. It isn’t going to have any code from the user_interface app.

1 Like
6

Agreed. Cyclic dependencies should be avoided and it is very likely you are going to run into issues, such as xref warnings. Ideally you would want to move this behind a configuration and have a explicit dependency from a -> b or b -> a, but not both ways (which is not even possible Mix-wise).

If you expecting too many options, then it likely means you have an artificial boundary between your applications and they should likely stick together.

2 Likes
7

It looks like refactoring the shared functionality into separate module(s) would be an option

8

In this instance, I’d probably hard-code the URLs on the basis that they are acting as 2 independent systems. I’d probably configure the base url for each so that it can be easily changed.

Assuming the admin interface is running on port 5000 and the web interface on 4000, then I’d configure it like:

config :admin, Admin.WebRouteHelpers,
  base_url: "http://localhost:4000"

config :web, Web.AdminRouteHelpers,
  base_url: "http://localhost:5000"

Then have a module like:

defmodule Admin.WebRouteHelpers,

# you can even ignore the first argument so it looks like a "normal" phoenix path helper
def admin_users_path(_, :index) do
  base_url  = Application.get_env(:admin, __MODULE__) |> Keyword.get(:base_url)
  base_url <> "/users"
end

If I was paranoid about these going out of sync then I’d have a 3rd application that is just for testing, that includes both applications as a dependency and assert the urls match.

This would ensure that things work even if you deploy your admin interface independently from the web interface e.g. admin.myapp.com

1 Like
9

And this is in fact how it’s going to be deployed/built with distillery. Okay thank you all. I’ll go with not making those apps dependent on each other at all, and hard-code the URLs the way @Gazler suggests.

10

For me this is a similar case to having, for example, front-end URLs on back-end in a SPA application (for example a URL in an email).

My preferred way of dealing with things like that is through configuration, similar to a way that @Gazler showed. Alternatively, you could have the configuration keep an MFA you’d call at runtime to produce the link. This, of course, also has the disadvantage of not being checked at compile-time, similar to other dynamic functions.

2 Likes