Were you on Facebook in 2005? Do you remember refreshing the page to get new notifications? Or refreshing a Gmail inbox to see if anything new came in? Or your Twitter feed? These days, you'll probably only refresh the page if you're feeling particularly impatient, because those kinds of updates appear automatically the moment they occur. That's all thanks to the transformative power of WebSockets and the real-time web.
A Brief History of "Real-Time"
I remember going into chat rooms when the internet first came to my hometown in the early 90's. Chat has always been real-time, so as a concept you can see that the real-time web isn't especially "new." In terms of application development, however, chat protocols back then were very strict, and focused on establishing chat connections only. For other types of applications, there was no "standard" implementation of real-time communication. Web browsers couldn't be expected to support it by themselves, and they usually needed third-party plugins to do the trick. Think Flash and Java "applets" - remember how clunky those could be?
Enter the "Web Socket"
var wsUri = "ws://WhoeverWeAreTalkingTo.com/"; websocket = new WebSocket(wsUri);
After that, you just need to set up a few rules to tell the page what messages to send, and how to respond to the messages it receives, and you're off and running.
Make it Compatible!
There is one drawback to the method above - it's only compatible with the most modern web browsers. For example, Internet Explorer versions 9 and below are not compatible with web sockets. Take a look at this chart to see what I mean. If you are building a real-time application for a business and you need to know it works for everyone, then you simply can't get by using vanilla WebSockets.
Thankfully there are a number of tools available that allow all browsers to support WebSockets. At ArcStone, we've zeroed in on Socket.io - its ease of use and reliability have made it the the de facto industry standard.
Where Does Node.js Fit In?
Say there are two sites - one built on Node and the other built in PHP. Each site receives three requests, X, Y, and Z, in that order. The PHP site would receive and process each request in turn. It wouldn't start processing Y until it had sent a response to X, and it wouldn't start processing Z until it had sent a response to Y. If X takes a long time, it will hold up Y and Z. In the Node site, the server would say "I've received the request for X, it's being processed. What would you like, Y? Oh look X, your response is ready now. Can I help you, Z?" Y doesn't have to wait for X to receive a response, and Z doesn't have to wait for Y. Depending on the nature of the various requests (and how long it takes to process each one), Z might get its response before X does. No single request can hold up the others.
Because Node is event-driven, it is ideally suited for real-time applications where a user clicking on a page might send multiple unrelated requests within the span of a few seconds. Or where thousands of users are making multiple requests all at the same time. There are trade-offs, though: Node doesn't have quite the same processing power per request that PHP or other backend languages offer. So if each request in your application is likely to use a high amount of server resources, Node may not be the best choice. Node and Socket are better suited for handling a high-volume of messages, when each message requires a relatively small amount of server processing power.
Is Real-Time Right for You?
That depends on what kind of application you'd like to build! Real-time applications are great for social networks and chat, or for apps that "track" sports scores, stock markets, or other news. If you'd like the application to track stock prices and calculate how that affects an individual user's retirement portfolio, you might be better off using a more traditional server-side language such as PHP. That doesn't mean you need to sacrifice that real-time feel entirely - you may have a real-time application written in Node that communicates with a more computationally intensive application written in PHP, for example. There is no shortage of options.