I’m trying to find the best practice when it comes to the subscription to topics. So let’s say that we have one topic “teams” where all there are a lot of broadcasts for the team updates(even the calls that some of the live_view modules don’t use or handle), would it be better to split this topic into a smaller broadcast pool of calls like teams, team_members, … and have more subscriptions when mounting the component? Will there be any downside of this?
Topics should be structured such that, when you subscribe to a topic, most messages that you receive are relevant to you. If you are filtering out or ignoring most messages that come to you, then the topics are probably overly broad and should be refined to allow more narrowly scoped subscriptions.
Each subscription from each process takes up a row (or two) in an in memory :ets table. While this isn’t a particularly large amount of space, it does mean that doing thousands or tens of thousands of subscriptions per client pid could begin to be a problem if you expect a large number of client pids. It’s a balance.
4 Likes
