Bringing realtime to your web applications

Few years ago only lazy didn’t say about bringing desktop application experience to the web ones. However in reality, it just meant that user actions didn’t always required page reload, but could change page UI dynamically. As for other application events, as a rule they were not handled dynamically.

Well, now you can find more and more web applications acting really like desktop ones. For example, Facebook and G+ have widgets which update automatically. You can keep the page untouched, but you will see anyway new status updates appear as your friends submitting. The same for notifications. Whenever a new one arrives, the counter changes and the notification list extends.

That seems to me as a trend worth to follow. I’ve been thinking of a solution to vivify widgets on my sites. Now I’m coming up with the following pattern.

WebSockets vs Server-Sent Events vs Long-polling

Apparently social networking is the banner of the nowadays web. Everybody intends bringing some features into his projects. Some of them require immediate notification. That is getting common, if you open a page with upcoming messages (status feed, notification subsystem, friends-list), you expected them being updated as soon as a new message (status, notification, friend-making action) arrives. As you well know, original web design allowed only one-way client-server communication (one requests, another one responds), though now HTML5 working group doing their best to fix it or rather to patch it. However, the web-projects are still using long-polling trick to emulate server-client communication.

Well, now new web browser versions appear every few months. Besides they update automatically. Thus a huge number of users have the latest browser versions, which support HTML 5 communication APIs. Is that the time to put long-polling away? Let’s find out.

Real-Time Updates with HTML5: Unlocking Server-Sent Events

Besides, already noted bidirectional communication channel, known as WebSocket, HTML5 propositions include also comet communication pattern by defining Server-Sent Events (SSE). WebSocket widely discussed by now, tons of server implementations are available and you can play already with fluent browser implementation under Chrome. However the second server-push technology of HTML5 yet stays in shadow.

Persistent Full Duplex Client-Server Connection via Web Socket

RIA is considered as one of the mostly particular to the modern Web feature, and often stands for the trend, according to which web-applications tend to desktop applications. Nonetheless the approach is very relative. Overwhelming majority of “rich” web-applications is still built on the “request-response” model. I.e. events of the client side can be reflected on the sever side, but not vice-versa. In order to make such a trivial thing as a chat, you have to go with tricks. There are different techniques to emulate bi-directional connections. Usually solutions of the kind are called Comet, thanks to Alex Russell of Dojo.