Menu
«
»

SockJS - web messaging ain't easy

August 22, 2011

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.

The landscape

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.

The new approach

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.

Early Socket.io development focused on message delivery in other words how to get the messages to and from web browsers. The contract with web developers was simple: here’s an asynchronous transport layer, you build your application logic in JavaScript on top of that.

A developer needed to write a thin JavaScript layer that joined Socket.io connections with the application the implementation details were left to developer. The application could be Node or using any other stack. It could be connected using just about any method, for example Redis, RabbitMQ or HTTP callbacks.

But recently Socket.io changed focus, it’s not a simple transport any more it starts to be a full messaging stack, featuring:

No silver bullet

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.

The next steps

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:

The future

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