Working With WebSockets
I’ve been tinkering around with Node.js quite a bit lately, trying to ramp up on a language that helps a front end engineer like me slice deeper into the back end and create more sophisticated applications. One of the side benefits of learning a new language is the gamut of novel technologies that a new language levies, such as WebSockets.
This sort of call and callback functionality has traditionally been the realm of AJAX-driven applications. Pepper a browser page with some AJAX calls, which are routed on the server in whatever language, with response pushed back up to the browser usually in the form of JSON or XML, and parsed by the browser without ever refreshing the page. Asynchronous HTTP.
Enter WebSockets. If AJAX was the main driver behind the “Web 2.0” phase of the Internet (though definitions differ), maybe WebSockets could fairly be called version 3. Essentially, WebSockets are an HTML5 browser technology that define a full-duplex socket “handshake” over a single TCP connection. Translated, WebSockets provide a way for connecting from the client to the server with a constant shared connection. Think of it like the telephone. Dial the number, place the call, and once connected, voices can talk back and forth without interruption (until the call is ended).
In fact, this is precisely what Node.js author–coder Guillermo Rauch did with his highly popular Node.js package, “Socket.io.” (For nerds/hipsters looking for a little more, “Engine.io” is it’s important twin.) Rauch took the Node.js events API and built a socket tool on top, complete with immediate event handlers and so forth. The whole nine yards.
A few of us at PubFactory recently tested Socket.io in a “Connect Four” engineering challenge. For sake of brevity, I’ll just state that implementation of a front-to-back-end connection was extremely simple to set up. In the matter of about an hour I was able to setup a very rough chat room that ran across the same IP address, over a fully functional WebSocket. (Unfortunately, Heroku, our deployment environment, does not support sockets, so we had to downgrade to XHR long-polling, which Socket.io easily allows, but WebSockets works locally in full splendor.)
Where will WebSockets take the web? My jest about “Web 3.0” may not actually be too hyperbolic. There’s already a growing list of developers and applications that utilize this stack. In fact, Node.js has become the nucleus for real-time frameworks reliant on WebSockets, including the likes of Meteor.js, Derby.js, SocketStream, which iterate far beyond Socket.io. These frameworks try and solve the problem, for example, of shared code (sockets and node combined tend to flatten the code stack), authentication over a constant connection, vertical and horizontal socket scalability, and other such problems. It’ll be interesting to see where it all goes.