Posted on by & filed under javascript.

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.

Node.js has a single-threaded, event-driven core. This translates into a language that allows for high concurrency, fast event-driven response, and easy round-trip client-to-server(-to-client) communication. Node.js is built in the same language that resides in the browser (JavaScript). This means that “real-time” applications that maintain state and communicate to the server without refreshing the browser can rely on the same browser-like listening behavior. In essence, the server acts very much like the browser, waiting for events to be called, and then operating when triggered on the callback.

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).

Where does Node.js come into this? Honestly, any server-side language can employ WebSockets. (Scala, might do it via “actors,” for example.) What sets Node.js apart is that the event-driven behavior of the browser that WebSockets rely on is also native to Node.js, as both have APIs that rely on JavaScript. Put another way, the event handling API is not only native to Node.js (in Node terms, you can reference it as require(‘event’).EventEmitter;), but can be extended to handle back-end WebSocket functionality.

In fact, this is precisely what Node.js authorcoder 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.

Tags:

Comments are closed.