Cleanly separating Verified Routes using Boundary

You can move what use MyAppWeb, :verified_routes does to a separate module, which you can independently scope with boundary.

You could also reverse the dependency by injecting the module for url generation e.g. using config. Works around Boundary a bit, but imo is the architectually cleaner approach.

I tried doing that, but it doesn’t change the output. Here’s how I added it:

defmodule MyApp.Notifications do
  use Boundary, top_level?: true
  # importing my custom module exposing what `verified_routes` does
  use MyApp.VerifiedRoutes
  # ...
end

The issue is that if I put this module under MyAppWeb, Boundary knows you’re still referencing the Web layer:

defmodule MyAppWeb.VerifiedRoutes do
  @moduledoc false
  def __using__(_) do
    quote do
      use Phoenix.VerifiedRoutes,
        endpoint: MyAppWeb.Endpoint,
        router: MyAppWeb.Router,
        statics: MyAppWeb.static_paths()
    end
  end
end

And I get this compile warning:

warning: forbidden reference to MyAppWeb
  (references from MyApp.Notifications to MyAppWeb are not allowed)
  lib/my_app/notifications.ex:17

If I try to put VerifiedRoutes out of the Web boundary, i.e.MyApp.VerifiedRoutes, I get these compile errors instead:

    error: undefined function url/1 (expected MyApp.Notifications to define such a function or for it to be imported, but none are available)
    │
 44 │           url(~p"/app/users/invitations")
    │           ^^^
    │
    └─ lib/my_app/notifications.ex:44:11: MyApp.Notifications.send_invitation/4

    error: undefined function sigil_p/2 (expected MyApp.Notifications to define such a function or for it to be imported, but none are available)
    │
 44 │           url(~p"/app/users/invitations")
    │               ^^^^^^^
    │
    └─ lib/my_app/notifications.ex:44:15: MyApp.Notifications.send_invitation/4

I don’t understand exactly why it fails to import the same code that works for MyAppWeb, so I couldn’t do it that way either.

The dependency inversion technique is something that I had heard of but never actually used. For now I’m seeing it as the only viable approach.

Thank you!

You could exclude the module just like it was previously done for the router helper module.

Not sure what this issue about the url function is on a quick glance.

I’ve used the “module in config” approach to solve this exact issue in an umbrella app.

It has a couple components:

• a module in MyAppWeb that exposes a URL-generation API
• code in MyApp that looks up a module and then calls functions on it
• config to set the key for MyApp to the module from MyAppWeb

defmodule MyAppWeb.NotificationUrls
  def for_invitation(invitation) do
    if invitation.user_id do
      url(~p"/app/users/#{invitation.user_id}/invitations")
    else
      url(~p"/auth/register")
    end
  end
end

defmodule MyApp.Notifications do
  ...
  def send_invitation(invitation) do
    to = url_module().for_invitation(invitation)

    ...
  end

  defp url_module do
    Application.fetch_env!(:my_app, :notification_urls)
  end

config :my_app, notification_urls: MyAppWeb.NotificationUrls

One downside of this simple approach is that the dynamic apply is very hard for most tools to “see through”, so you probably won’t get compile-time warnings if something’s incorrect (calling for_invitation with the wrong arity, etc)

You can mitigate most of that with some additional boilerplate-y code:

• extract the Application.fetch_env! part and the call into a separate module in MyApp
• create a @behaviour that it implements
• also implement the behaviour in MyAppWeb.NotificationUrls

Saša’s book helped to get me started long ago. So, this is clearly a solid tool built by an expert.

I’m in the middle of restructuring a large codebase, and boundary came up. My layout is monorepo (imagine lib → {foo, bar, baz}), currently via manually ensuring a directed dependency graph. The original inclination for such manual enforcement was simply to use grep to look for any circular refs, but I like the idea of boundary enforcing this programmatically.

The lib looks well-vetted. Has anyone had luck using this for larger codebases? Any feedback, tips?

There was a new talk from Saša recently published that talks about the process of both incorporating boundary into a large new codebase and also working towards removing projects from umbrella format:

I found it a great talk, and there’s no better source than the author about this library