tmbb
I was thinking that it would be cool to notify clients in real time when something changes in the Repo. My question is: where should I put the notification code? The controller or the context?
If I put them inside the context I’m sure all Repo changes will be captured and will generate notifications (this is probably not a good idea, but let’s assume it is). But this couples the context to the web part of my application, which is undesirable, right?
If I put them inside the controller, I keep the separation between the web part and the context, but I can’t be sure I’ve captured all changes.
Should I have a NotificationManager module that tests whether if the web application is running before sending a notification? Is this level of “uncoupling” enough?
I’m not sure I’ll ever want to do this in production, so this is mainly a theoretical question about design.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 5 to 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
tmbb
Thanks, that’s what I thought too.
I can see some advantages in doing this and must investigate further. Thanks
I’m aware of that. That would require having the DB itself notifying my code. I’m planning on only interacting with the DB using ecto, so that’s something I’m not interested in.
bobbypriambodo
Indeed, yep, your solution would scale better than mine. Using dedicated message queues or process should be better in the long run…
NobbZ
I do not think that the “context” should know who is interested in updates. It should just know that there might be someone.
If the context itself were iterating all the possible receivers each time there is an update, it could take quite a long time and massively influence the speed of database access.
Therefore I opt for a single “relay” as described in my post, but aside of that our ideas are similar.
bobbypriambodo
Just abstract thinking here (since I’m currently at work
), I would think this is a perfect use case for Pub-sub pattern. As we know, the data of your app is handled inside its own contexts outside of the web layer. How I imagine it is that you have a context that exposes a
subscribe_to_updatesfunction. The client (in this case, your web layer or something) calls that function on start and provide a handler (callback?) specifying what to do when it receives an update notification.Everytime there’s an update, the context will iterate to the registered subscribers and call their respective handlers. This way you can decouple the subscriber from your context.
Now, how to implement that in Elixir seems to be an interesting challenge ^^
NobbZ
Sine I’m on mobile only brief…
If something generates an update message it should be the context or even closer to the repo. It will always emit a message then to a genserver, which then relays this message to any topic, beam process or message queue or whatever you want and has subscribed in any way. Perhaps even layered through a tree like structure of processes.
This way you’ll get also changed made by non web parts of your application. But you still won’t catch changes that were made directly in the db.