Something I started playing with in Cacophony 2.0-pre5 was using WebSockets to send dynamic data updates to the front-end, instead of polling a REST end-point. Specifically, I did this for the status page as its changes of state weren't directly associated with an action, since they were heavily asynchronous (a root republish or followee refresh could take minutes to complete).

Internally, it uses a create-update-delete key-value event stream structure, where the key and value types are determined by the use-case. This also allows the mechanism to be easily generalized in the front-end and back-end. In the back-end, a generic key-value projection can be created from any data source, allowing an arbitrary number of listeners to connect and be immediately brought up to date with the current data. In the front-end, callbacks for these events can be provided into a generic helper where the special meaning of key and value can then be decoded in special ways for each page.

Yesterday, I was playing with using this design for the prefs page but it didn't really work, so I ended up leaving that case in the REST-based design. At first, I tried to make each pref element into a key-value entry, but this required generalizing the UI in a way which made actually working with this data harder to understand and more tedious to update. Also, this case is pretty trivial so the REST-based design was just more obvious (as there is no asynchronicity or generalization to the data).

So, while I still think that this WebSocket event-based design has merit, and will likely be used for any other data view which has some asynchronicity and could benefit from the generalization, trivial cases should probably continue just using the REST-based approach.

Jeff.