Avoiding a dependency cycle when using Router.Helpers

jarrodm

Hi Phoenix ppl,

I have a separate notifications service, and for some time now I’ve simply been pushing all the arguments it needs over to the service including the URLs it needs.

It simplifies dependencies, but it means that the web service had to gather all the information needed according to the whims of whatever the notification templates needed. It also meant that the data could be stale by the time the notification was rendered, and this arrangement has fallen apart now that I want some notifications to be polled instead of triggered.

Recently I’ve refactored to the notification service to pull the information it needs from the database, but it also needs to generate the URLs. This causes a cycle with the business logic in the web service needing to trigger new notifications, but also the notification service needing access to the business logic, data model and router in the web service.

My solution to this is to trigger the notifications service at the API/controller level (probably where it should have been all along), and to move the business logic and data model out to its own dependency. But I think I also need to clone the url helpers of the router as it depends on the controller creating another cycle – right?

It’s not a huge deal, as any inconsistencies between the two could be caught in unit tests, but the redundancy does seem like a place for bugs to emerge… and there might be a better solution?

I’m thinking this is a common problem as projects grow, and I’d be keen to hear how other people have tackled this problem. Thank you.

10 comments

/phoenix #router #circulardependency #routerhelpers

4 1228 10

2022-08-14 14:10:38 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

jarrodm

I feel like I’ve failed to communicate the problem, so I’ll give it one more shot! Has anyone wanted to share their router paths with another application, which the web server depends on? If so, how did you avoid the dependency cycle? Can it be done without duplicating functionality of the router?

Post #1

fuelen

Just created MyApp.Links module which contains URLs I need. Typically, you don’t need a lot of URLs, and it is not a big pain to support duplicated functionality.

Post #2

LostKobrakai

Your controller could pass in all the urls needed by „Business Logic/Repo“. That way there‘s no nedd for the dependency back into the web service.

Post #3

fuelen

Could you elaborate? If I want to send email/SMS etc in background, how it is related to controller?

Post #4

LostKobrakai

It doesn‘t really matter too much what you do and when. If BusinessApp is supposed to be decoupled from WebApp, but also needs to know details only WebApp is aware of (like urls), then one solution would be to provide these details whenever WebApp calls api of BusinessApp. Something like BusinessApp.start_registration_flow(user, WebApp.business_routes()). That way BusinessApp doesn‘t need to call into WebApp again to get to know those urls.

Post #5

jarrodm

Thank you @fuelen . You’re right, it’s not a big pain to duplicate, and I’ll be verifying with unit tests to ensure they’re consistent with the router. I’ve become accustomed to finding elegant ways to deal with just about any problem on these forums, and this is the first time I’ve hit anything close to friction with Phoenix/Elixir

Post #6

jarrodm

Thanks @LostKobrakai . I’ve run into a problem where the service can now be triggered not just by the web service (e.g., on an API call), but also indirectly by updates to the database. It’s in this second use case where I’ve come unstuck, as it is invoked by the supervisor/Oban.

It might be possible for the web service to initialise the notifications service and pass the router module to it?

Post #7

LostKobrakai

This indeed makes it a bit more tricky, as the job might be executed at a later time (e.g. after a deployment changed a url). In this case I’d probably pass a callback module with functions, that can be called at the time of execution. The behaviour of that module would live in BusinessApp, so its a clear dependency of who is defining the interface of it vs. who implements it.

Post #8

jarrodm

In this case I’d probably pass a callback module with functions, that can be called at the time of execution. The behaviour of that module would live in BusinessApp, so its a clear dependency of who is defining the interface of it vs. who implements it.

This is close to what I was thinking. I’ve made a behaviour class that lives in the BusinessApp which I’m using to generate urls across the Apps. Currently I’ve cloned the route logic in the BusinessApp’s implementation, and the WebApp simply uses the Router.Helper, with unit tests to verify they are equivalent. I intend to have some nodes that are purely for Notifications, so it’s my preference to avoid one initialising the other.

Post #9

fuelen

It is not always that simple, as URLs are usually parameterized, and with this approach there may be a need to store them in some DB in order to be processed later.

Post #10

— All posts loaded —