Only recently I started messing around with Websockets, even though browsers like Chrome and Firefox has been supporting them for a while now, and I must say, I’m impressed!. One can’t help to wonder why, WHY???, didn’t I use them before.
Definition (in plain English):
A Websocket is a bi-directional channel between two points. Most examples will illustrate a Server and Client (browser) but in reality it could be client-to-client or server-to-server, there is no limitation as to what you can do with it.
So enough with the definition, lets jump on a real world example.
Real Life Example
Here is the problem we faced: we needed to display an iframe which in terms displaying some data we didn’t want to bother with, unfortunately, if you dealt with iframes in the pass you will know that they are a major pain in the neck. To be more descriptive, imagine a web page with a section in it that uses a iframe instead of plain HTML, once you render the iframe and it loads the data (which I will like to point out, could come from another domain) it looks as if the page was entirely done and provided by your server when in fact it is being fed by two different sources.
Of course you don’t see the harm yet, and are probably wondering what the real issue is, so lets dig deeper. When the user interacts with the iframe the rest of the page is not aware of what is happening because of the nature of the iframe itself, it allows you to render a HTML page within a HTML page, which it has its advantages and disadvantages, one of which is security, you see, when the iframe is rendered, it is self-contained, meaning, for security reasons it can’t interact with the page hosting it.
So as you see, we now had a problem in our hands which is how the heck are we going to know when the user is done with the iframe and will like to continue to the next the page.
Here is where Websockets come to the rescue.
Technically, a Web Socket has 4 states, Open, Close, Message and Error.
Open or onOpen allows you to create the socket.
Close or onClose, closes the socket as you probably guessed it.
Message or onMessage allows your to push a message to the other end which doesn’t have to be a string, it could be a callback function, thus triggering some event on the page.
Error or onError allows you to do something when the connection fail or the Websocket can’t be created.
With that said, we decided to create and open a Websocket and then (once that was in place) created a iframe using jQuery and injecting it on the page after the DOM was done. The next step was to create a callback in the iframe so when the user is done with the iframe it will call the server and we would use this signal to communicate to the browser what to do next.
Basically, this would allow us to let the customer customize the iframe with whatever junk they wanted and we would only care about the clicking of the “continue” button in order to take them to the next page.
Of course you could probably argue that after clicking on the “continue” button the server could route the user back to the next page but this could be seen as a “old school” approach where you are using the traditional posting to create an interaction between server and client, but this is 2012, so forget about that and start embracing new technology.
So as you can see, we used Websockets in this case to listen to events on the page where we would normal be unable to listen or act upon due simply to the browser securities and limitations.
Here are a few things to keep in mind if you decide to implement Web-Sockets into your application:
- Since a Websocket is an exclusive and private communication channel between two points, maintaining a big number of sockets at one time could be very demanding. Make sure you can handle the load.
- Websockets are only supported by modern browsers (IE9, Firefox, Chrome, Safari, etc), although there are newcomer projects out there such as SocketJS which aim to support and emulate Websockets for older browsers, or what I’ll like to call Dumb Browsers.
- Websocket could become a challenge over Proxy Servers as well as Load Balancers. However, Websockets CAN work perfectly fine over a Load Balancer such as Citrix NetScaler when setup properly. Remember, nothing in this life is impossible.