RX vs messaging queues like rabbitmq or zeromq? [closed]

Question

I'm quite new to these high level concurrency paradigms, and I've started using the scala RX bindings. So I'm trying to understand how RX differs from messaging queues like RabbitMQ or ZeroMQ?

They both appear to use the subscribe/publish paradigm. Somewhere I saw a tweet about RX being run atop RabbitMQ.

Could someone explain the differences between RX and messaging queues? Why would I choose one over the other? Can one be substituted for the other, or are they mutually exclusive? In what areas do they overlap?

Answer 1

It's worth clicking the learn more link on the [system.reactive] tag, we put a fair bit of info there!

From the intro there you can see that Rx is not a message queueing technology:

The Reactive Extensions (Rx) is a library for composing asynchronous and event-based programs using observable sequences and LINQ-style query operators. System.Reactive is the root namespace used through the library. Using Rx, developers represent asychronous data streams using LINQ operators, and parameterize the concurrency in the asynchronous data streams using Schedulers. Simply put, Rx = Observables + LINQ + Schedulers.

So, Rx and message queueing are really distinct technologies that can complement each other quite well. A classic example is a stock price ticker service - this might be delivered via message queuing, but then transformed by Rx to group, aggregate and filter prices.

You can go further: much as Entity Framework turns IQueryable<T> queries into SQL run directly on the database, you can create providers that turn Rx IQbservable<T> queries into native queries - for example a Where filter might leverage the native filtering capability that exists in many message queueing technologies to apply filters directly. This is quite a lot of work though, and hard.

It's much easier, and not uncommon to see message queue messages fed into an Rx Subject so that incoming messages from a queue are transformed into an Rx stream for easy consumption in the client. Rx is also used extensively in GUIs to work with client side events like button presses and text box changes to make traditionally difficult scenarios like drag-n-drop and text auto-completion via asynchronous server queries dramatically easier. There's a good hands on lab covering the later scenario here. It was written against an early release of Rx, but still is very relevant.

I recommend looking at this video presentation by Bart de Smet for a fantastic intro: Curing Your Event Processing Blues with Reactive Extensions (Rx) - including the classic Rx demo that writes a query over a live feed from Kinect to interpret hand-waving!

Answer 2

Could someone explain the differences between RX and these other messaging queues?

Rx is simply an abstraction over Events (any kind of event!). Receiving a message from a distributed queue is an Event, and often, ZeroMQ / RabbitMQ solutions often have to use and combine different Events quite a bit, which Rx is very good at.

So often, Rx makes writing ZeroMQ / RabbitMQ apps much easier than it would be otherwise :)