I have been wanting to try out a few technologies for a while and tried them all out in a demo that allows concurrent distributed users to edit the same web form. All the users see edits happening in real time. The code is on github, and the README there has more detail than I supply here. The demo works, but the README mentions things that a real-world shared form would need added or at least considered.
These are the technologies I used:
I also touched on a couple other primitives that would be needed to go beyond the demo stage:
I also used good old jQuery.
The amazing thing about this experience was that all these technologies worked wonderfully, without a hitch. They were pretty easy to put together. One reason is that each has great documentation, although the Gorilla WebSocket module’s best documentation is external to it, in a blog post by its author, Gary Burd:
While driving, I listened to a bunch of conference talks and tutorials on WebSockets. I found out that about half of the presentations dwell on fall-back strategies, ways of supporting users with lame browsers or lame web proxies. It turns out that there are a few libraries created expressly to provide transparent fall-back mechanisms when the client can’t use WebSockets.
- Socket.IO is the mainstream option, and
- Sock JS is the leaner, newer option from the RabbitMQ team at VMware.
There isn’t any Golang server-side Socket.IO or Sock JS implementation that is “blessed” by either of the two projects or even stable at this time. It leaves me wondering whether I could put Sock JS in the client and just provide support for long-polling AJAX in the Golang server as the sole fall-back mechanism.