goncalotomas
Cleanly separating Verified Routes using Boundary
I’m working on a Phoenix LiveView app that uses boundary, and we’ve bumped into warnings writing out a way to do notifications. There are a couple of tricks that would remove these warnings, but I care about the right way to model data and to organize the code. ![]()
Here’s a rough example of the code I’m working with:
defmodule MyApp.Notifications do
@moduledoc """
The Notifications module is responsible for managing user notifications - both in-app and email.
"""
use Boundary, top_level?: true
# importing verified routes
use MyAppWeb, :verified_routes
def send_invitation(invitation) do
to =
if invitation.user_id do
url(~p"/app/users/invitations")
else
url(~p"/auth/register"))
end
MyApp.Mailer.deliver_invitation_email(invitation, to)
send_invitation_notification(invitation)
# ...
:ok
end
defp send_notification(invitation) do
# ...
end
end
The real code is a bit more complicated, but hopefully this illustrates the issue.
We’ve configured Boundary to reject any calls to from the MyApp context to the MyAppWeb context, which makes this module not pass the boundary checks:
warning: forbidden reference to MyAppWeb
(references from MyApp.Notifications to MyAppWeb are not allowed)
lib/my_app/notifications.ex:17
It makes sense to prevent access to the Web context from the non-Web, but in this case we’re, were just trying to use verified routes so that the links for the invitations are verified to exist. Previously we could use Phoenix.Router.Helpers, but from the docs, it looks like the routes module helper is deprecated, so no help there.
Moving the logic that switches between the possible URLs inside the Mailer doesn’t seem helpful, since it looks like we’re leaking the logic around Invitations when Mailer should just care about sending email.
We’ve also toyed with a few ideas that basically revolve around replacing the Route Helpers module, but quickly ran into the thought of “there’s got to be a better way to do this”.
Can someone help us organize our code a bit better?
Thanks! ![]()
Most Liked
LostKobrakai
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.
goncalotomas
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 ![]()
al2o3cr
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
MyAppWebthat exposes a URL-generation API - code in
MyAppthat looks up a module and then calls functions on it - config to set the key for
MyAppto the module fromMyAppWeb
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 inMyApp - create a
@behaviourthat it implements - also implement the behaviour in
MyAppWeb.NotificationUrls
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








