No Comet, Hacking with WebSocket and Akka

Over the weekend I upgraded my Chrome to the developer channel and played around a bit with Web Sockets. It's really really exciting and for sure will make us think of Web applications in a different way. Web Sockets have been described as the "TCP for the Web" and will standardize bidirectional communication technology for Web applications.

The way we think today of push technology is mostly through Comet bsed implementations that use "long polling". The browser sends a request to the server and then waits for an event to happen and then sends a response. The client, on getting the response consumes it, closes the socket and does a new long polling connection to the server. The communication is not symmetric and connections can drop off and on between the client and the server. Also, the fact that Comet implementations are not portable across Web containers make it an additional headache to portability of applications.

Atmosphere offers a portable framework to implementing Ajax/Comet based applications for the masses. But still it does not make the underlying technology painless.

Web Sockets will make applications much more symmetric - instead of having long polling it's all symmetric push/pull. Once you get a Web Socket connection, you can exchange data between the browser and the server through send() method and an onmessage event handler.

I used this snippet to hack up a bidirectional communication channel with an Akka actor based service stack that I was already using in an application. I needed to hack up a very very experimental Web Socket server, which did not take much of an effort. The actors could do message exchange with the Web Socket and communicate further downstream to a CouchDB database. I already had all the goodness of transaction processing using Akka STM. But now I could get rid of much of the client code that looked like magic and replace it with something that's more symmetric from the application point of view. It just feels like a natural extension to socket based programming on the client. Also the fact that Javascript is ideally suited for an event driven programming model makes the client code much cleaner with the Web Socket API.

Talking about event based programming, we all saw the awesomeness that Ryan Dahl demonstrated a few weeks back with evented I/O in Node.js. Now people have already started developing experimental implementations of the Web Socket protocol for Node.js. And I noticed just now that Jetty also has a WebSocket server.