A follow-up to earlier decisions around using WebSockets to communicate.

In this audio clip, I talk about how the design did work out as well as the initial indications but there were a few other points I wanted to make.

First of all, I ended adding a "special" value which can be sent as "out-of-band" data associated with a single WebSocket. This was used in cases like "this followee is currently being refreshed" without needing that singular use-case to listen on a more general application state socket (although that may eventually be the right solution - seemed heavy-weight and convoluted for this case, though).

Second of all, I found that sending mutative commands back down these streaming update WebSocket connections was generally just an over-complicated way of doing something which a traditional REST end-point already does very easily. It may make sense to do this in cases where the server has some notion of "state" associated with the active connection, but the general cases where it _could_ be used seemed to be a poor fit.

Thanks for listening,
Jeff.