Posts written by Marek MajkowskiMay 14, 2012
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.
February 23, 2012
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?
January 24, 2012
SockJS version 0.2 has been released:
You can test it in the usual playground:
November 30, 2011
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
Hey, we can do that!
October 19, 2011
There’s a lot of hot stuff happening in the web technology lately.
browser-side and server-side.
At the RabbitMQ HQ we’re interested in developments in the wide world of
messaging - namely WebSockets and related technologies.
September 26, 2011
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.
September 13, 2011
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
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
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.
July 8, 2011
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.