1. 26
  1.  

  2. 7

    Well, there is built in Phoenix.Presence that is meant exactly for such use case - tracking users on-line. It will track all users and will transmit only diffs of changes instead whole list of users each time.

    1. 3

      Ah, yeah, that’s great. And Presence looks to be built on top of PubSub.

      Using this module defines a supervisor and a module that implements the Phoenix.Tracker behaviour that uses Phoenix.PubSub to broadcast presence updates.

    2. 4

      This story illustrates one thing I have found with LiveView as well. It is really cool and a lot of fun. But, getting it to working doesn’t mean that’s how it “should” work. That’s true for any technology, but it seem especially true in Elixir/Erlang since they are built so specifically with all the processes and GenServers etc.

      1. 2

        I didn’t know of LiveView before and am halfway down the article. So far it reads like this: (1) “There is this new technology whose’ idea is to avoid any computation on the client, just the UI there, storing all the interaction state on the sever. Much easier to program that having to write multi-party programs.” (2) “Well actually when you have a lot of clients, this overloads the server”. Well, duh? Am I missing something here?

        1. 3
          1. There you are correct.
          2. Not really. The problem there is volume of the sent information as sending list of all participants over and over again to everyone is quite expensive. The second part can be understood as “sending less data will make servers go faster”. Elixir (with or without LiveView) can scale a lot.

          So the problem there is that author forgot, that their approach will result in quadratic volume of messages on each entry/leave, and that caused problems.

          1. 2

            Thanks for the clarification!

            Actually I read further and it looks like there is no quadratic send-all-participants-to-all-participants behavior here, juse a handful of “admin” sessions will receive the list of all participants, but this already proves to be a scalability issue when many participants login quickly. (One would expect the right approach to be sending a differential/incremental description of the change in participant list, instead of re-sending all participants each time.)

            1. 2

              One would expect the right approach to be sending a differential/incremental description of the change in participant list, instead of re-sending all participants each time.

              That is exactly how Phoenix.Presence that I have mentioned above works. It simply sends diffs after initial information about all participants.