I have a web app that I want to introduce real-time functionality to. It consists of information dashboards, where a dashboard visualizes multiple widgets. A widget can also be subscribed to by other dashboards.
When designing the channel architecture, would you put the functionality for updating widgets in the dashboard channel, or create one for each individual widget? The first would make the dashboard channel more complicated, but generally lead to less channel connections being made. The latter would move the responsibility to its own channel, handling cases where a widget is sending updates to multiple dashboards.
“It depends.” If the widgets have a lot of input handlers or custom handle out functions, then it may be better to do 1 Channel per. Keep in mind that 2 Channels on the same Socket connection is only 1 TCP collection and 2 channel processes. Processes are cheap, so it’s generally not a problem to have a lot of them.
If the widgets are just getting data from the backend, and there isn’t many custom handler functions, then I might go on the side of 1 Channel (topic) for all widgets.
I’d optimize for the cleanest code here, rather than worrying about performance of the Channels. The exception to this is if you’re writing code that will go to many many simultaneous users.
Thanks for the input. What if there can be thousands of users connected to a single dashboard, would individual channels for widgets still perform well enough? Pretty sure that it shouldn’t be a problem in practice before a long time, but wondering, theoretically speaking.
Without seeing your app, I’d say that in general that’s fine. Thousands of users really isn’t a problem for Phoenix Channels, even with a single server processing them.
One Channel or multi Channel really won’t have a ton of long term impact. Multi socket does because connections are higher overhead. Use what is most comfortable for you right now.
