Archive for the 'Web Messaging' Category
May 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?
February 21, 2012
Here at RabbitMQ HQ we spend quite a lot of time arguing. Occasionally, it’s about important things, like what messaging really means, and the range of different APIs that can be used to achieve messaging. RabbitMQ and AMQP present a very explicit interface to messaging: you very much have verbs send and receive and you need to think about what your messaging patterns are. There’s a lot (of often quite clever stuff) going on under the bonnet but nevertheless, the interface is quite low-level and explicit, which gives a good degree of flexibility. Sometimes though, that style of API is not the most natural fit for the problem you’re trying to solve - do you really reach an impasse and think “What I need here is an AMQP-message broker”, or do you, from pre-existing knowledge, realise that you could choose to use an AMQP-message broker to solve your current problem?
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.