For quite a while here, at RabbitMQ headquarters, we were struggling to find a good way to expose messaging in a web browser. In the past we tried many things ranging from the old-and-famous JsonRPC plugin (which basically exposes AMQP via AJAX), to Rabbit-Socks (an attempt to create a generic protocol hub), to the management plugin (which can be used for basic things like sending and receiving messages from the browser).

Over time we’ve learned that the messaging on the web is very different to what we’re used to. None of our attempts really addressed that, and it is likely that messaging on the web will not be a fully solved problem for some time yet.

That said, there is a simple thing RabbitMQ users keep on asking about, and although not perfect, it’s far from the worst way do messaging in the browser: exposing STOMP through Websockets.

Or: How to properly do multiplexing on WebSockets or on SockJS

As you may know, WebSockets are a cool new HTML5 technology which allows you to asynchronously send and receive messages. Our compatibility layer - SockJS - emulates it and will work even on old browsers or behind proxies. WebSockets conceptually are very simple. The API is basically: connect, send and receive. But what if your web-app has many modules and every one wants to be able to send and receive data?

SockJS version 0.2 has been released:

• https://groups.google.com/group/sockjs/browse_thread/thread/79893c8545c49f06

You can test it in the usual playground:

• http://sockjs.popcnt.org/example-cursors.html
• http://sockjs.cloudfoundry.com/tests-qunit.html

We were wondering how to present SockJS and its possibilities to a wider audience. Having a working demo is worth much more than explaining dry theory, but what can you present if you are just a boring technologist, with no design skills whatsoever?

With questions like that it’s always good to open a history book and review previous generation of computer geeks with no artistic skills. What were they doing? On consoles with green letters they were playing geeky computer games, MUDs (Multi User Dungeons) were especially popular.

Hey, we can do that!

There’s a lot of hot stuff happening in the web technology lately. JavaScript seems to be bearing the torch, both browser-side and server-side. At the RabbitMQ HQ we’re interested in developments in the wide world of messaging, and we’re particularly excited about the JavaScript angle on messaging - namely WebSockets and related technologies.

I was asked to do a short presentation during the PubSubHuddle meetup. The talk was about current development of WebSockets, its issues and building web applications using them.

WebSocket technology is catching up, but it will take a while before all browsers support it. In the meantime there are loads of projects that aim to substitute for WebSockets and enable ‘realtime’ capabilities for web apps. But all attempts solve only a part of the general problem, and there isn’t any single solution that works, is scalable and doesn’t require special deployment tricks.

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.

I fundamentally disagree with the APIs exposed by our current AMQP client libraries.

There is a reason why they’re imperfect: we intentionally avoided innovation in APIs since the beginning. The purpose of our client libraries is to expose generic AMQP, not any one view of messaging. But, in my opinion, trying to map AMQP directly to client libraries APIs is just wrong and results in over-complication and abstractions hard to use.

There is no common ground: the client libraries blindly following AMQP model will be complex; easy to use client libraries must to be opinionated.