The idea of ‘realtime web’ or messaging using web browsers has been around for quite some time. First it was called ‘long-polling’, then ‘Comet’, the latest incarnation is named ‘WebSockets’. Without doubt it’s going in a good direction, WebSockets is a neat technology.
But during the fight for realtime capabilities we’ve lost focus on what is really important how to actually use messaging. In the web context everything is request-response driven and marrying a typical web stack to asynchronous messaging isn’t easy.
There were many attempts to create a generic component that could join the web stack and just deal with ‘messaging’ in a similar way to a database dealing with data.
There is a problem though, the asynchronous nature of messaging and browser cross-domain restrictions mean that in order to get ‘Comet’ working, you need to use a particular web stack. A classic case of vendor lock-in.
At least that’s how it was in the past. You could have a web-messaging framework, but you were pretty much tied to it.
Until, not long ago, the Socket.io project emerged. It’s build on Node.js, which gives it a unique position not only everything in Node.js is already fully asynchronous (there’s almost no way to screw it up) but also it used a common language already used in the web environment.
But recently Socket.io changed focus, it’s not a simple transport any more it starts to be a full messaging stack, featuring:
But here’s a catch: if you build messaging semantics the messaging library starts to be a framework and quickly becomes tied to a platform.
Think about it, even if you try to build a simple ‘broadcast’ abstraction, you inevitably need to answer many nonobvious questions:
Bear in mind that ‘broadcast’ is a very simple abstraction, in practice everyone uses messaging differently and it’s very hard to create a generic messaging framework. Most of the decisions made by messaging framework are in fact application specific:
I’m glad Socket.io development is going well and I keep my fingers crossed for it. But in my opinion it focuses on the wrong problem: I don’t need another opinionated messaging framework which is tied to a particular platform.
Instead, I only need a stable transport layer.
Socket.io showed the way - there is a room for a simple and stable library that would solve the message-delivery problem, that would enable WebSockets-like API’s until a native implementation is widely deployed. All that without defining the messaging model, please.
Here is my reply: SockJS - a library with WebSockets-like API that focuses only on the transport layer. Although project is young, in my opinion it’s already better than other libraries like that.
The project is split in two parts:
If you want to see it running, here are a few live deployments hosting QUnit tests:
There main assumptions behind SockJS are:
Solving message delivery problem is just a first step. The ultimate goal is to create a generic messaging framework for web apps, but it’s not going to be easy. It’ll take a lot of work and many failed attempts. That’s why it’s so important to have a stable, well designed, reusable transport layer handy.
(Article also available on github pages)
Written by: Marek Majkowski
Categories: Web Messaging