This line of code executes as part of a queue that broadcasts messages to specific clients. however, I would like to check if a channel is currently active first before sending the broadcast to the channel. in this way, I can avoid sending broadcasts to clients that are offline.
What do you mean âactiveâ? Every channel is technically active all the time. If nothing is listening it just goes into the abyss very efficiently. You can use presence to determine âwhoâ is listening, but thatâs not really necessary if itâs cheap to generate and send as if there are no listeners then it doesnât do much.
As Overwind alluded, itâs almost always better to simply broadcast and not worry about checking. Broadcasts are cheap and checking first for activity will be expensive and race prone.
If you do want to check, you can use Phoenix.Tracker to track each connected Channel. This provides a way to query for activity before doing the broadcast. I do this in https://github.com/pushex-project/pushex/blob/master/lib/push_ex_web/channels/push_tracker.ex to avoid broadcasting data to non-connected topics. This is because we have a somewhat high âmiss rateâ of pushes, and our volume is high enough that avoiding the networking is useful.
This could be beneficial if you are doing something like a database or external resource lookup per broadcast.
just keep in mind, depending on your consistency requirements, you can miss broadcasts for clients that are recently active. Tracker is eventually consistent, with a default broadcast period of 1.5s, so you you will necessarily miss some broadcasts by checking for activity if you use the tracker approach. This may be fine for some usecases, but not others. One option is you can allow missed messages with an eventually consistent lookup by attaching some data on the broadcast that lets the caller know they are behind, then they hit whatever API they need to find the missed data. That said, unless you have specific usecases like Steve has, broadcasting as fire and forget is going to be much less complex.
Absolutely this. The defaults for Phoenix will work for most applications. The approach broadcast takes is designed to get messages to all listeners, which is probably what you want.
I wanted to give the approach, but you should make sure you are okay with the tradeoffs and that the benefits are worth it for you.
I did notice that you have WyzerOnboarding.Accounts.get_access_token(user) in your call. If thatâs the reason you donât want to broadcast, you could actually handle slightly differently. One option for making sure the database is only hit when a Channel is connected is to broadcast the message WITHOUT the token, and then implement a custom handle_out callback that fetches the token and adds it to the payload. handle_out is invoked in the Channel process itself, so by definition it will only run if a Channel is alive. Thereâs a slight performance cost to handle_out in specific circumstances, but I donât think that theyâd apply to your app given the message youâre broadcasting.
You are right, that makes sense but i guess i would go with the fire and forget approach⊠the get_access_token is a db call which is inside a line that executes only for some types of users, and basically speaking, it is not the case of millions or thousands of users. considering the slight performance cost of handle_out and using of Phoenix.Tracker with its lower broadcast period might end up in much more expensive task compared to fire and forget. over optimisation usually leads to more problems and larger code base than usual
