I could probably help you out with the interface. I have been looking for an excuse to try out a js client side framework I haven’t yet used. Would you have any preferences?
Why did you build a custom websocket implementation along with fallback to polling JSON endpoints when the Phoenix Socket library already has all that built in along with back-off procedures on connection failure (where wobserver just waits 5s before each retry when a connection died) among more including longpolling fallback? As well as doing things like observing a specific node would have fit in fantastically into a Phoenix Channel without the odd state handling needed. ^.^
Also adding cowboys low-level socket handlers is fairly difficult with Phoenix’s Endpoint… ^.^;
To put those in, as far as I can see you have to gut the Phoenix endpoint handler and basically re-do some of it manually…
Native Phoenix ‘Socket’ support can be added with a couple more callbacks in lib/wobserver/web/client_socket.ex, as I’ve already done at https://github.com/OvermindDL1/wobserver/blob/master/lib/wobserver/web/phoenix_socket.ex (separate file just because I did not want to pass in the callback module manually, plus cleaner) and submitted a PR for. ^.^
Really should look into using Phoenix Sockets straight though, the abstraction of websocket/longpolling is very nice and the channels allow you to abstract commands better (plus the broadcasting support lets you query once but broadcast the information to multiple people observing instead of each causing an individual query, which would reduce the work-load, and by using the pubsub system then libraries that use wobserver could get updates as well without needing to poll), but this PR is really all that is needed for compat.
As you can see I sent a set of issues and the above PR, other than the assets issue (that I still cannot figure out, I’m thinking that you should keep the assets.ex file in the git repository, not just on hex.pm), it overall it looks fantastic!
