Very unfortunate title choice for an otherwise interesting post that praises LiveView

Not quite the proper takeaway for all points:

1. Large payloads over PubSub by themselves are just fine. We actually broadcast entire ets tables of presence information when we replicate data for new nodes, so by itself this isn’t a problem

2. This is the key takeaway here. Publishing events at scale must consider downstream subscribers. In this case publishing the entire user list for any individual user change was the mistake, rather than deltas of joins/leaves (or presence)

3. We won’t send anything on the wire if there is an empty diff, so I’d need to know more about this particular case.

Fail your way to success

TL;DR for those who haven’t read the well written article yet:

1. Avoid large payloads in Phoenix.PubSub if possible
2. Throttle PubSub events at the sender level to avoid clogged process inboxes
3. Using assign/3 in LiveView always causes an update via Websocket, even if no changes were made

In regards to point #1, it seems like the argument here is that instead of one process querying the DB and sending the result to the other processes as a PubSub payload, it’s better to have the process send a message without payload, and then each process makes its own DB query. Is this always true? I use payloads in my PubSub broadcasts sometimes to minimize DB queries; now I’m wondering if this was a mistake.

I broadcast 5,000 updates and my laptop didn’t crash.

takeaway #1 for me: try to do testing that is close to reality.