'Reactive' Development Turns 2.0

electronic convict writes First there was "agile" development. Now there's a new software movement—called 'reactive' development—that sets out principles for building resilient and failure-tolerant applications for cloud, mobile, multicore and Web-scale systems. ReadWrite's Matt Asay sat down with Jonas Bonér, the author of the Reactive Manifesto (just released in version 2.0), for a discussion of what, exactly, the reactive movement aims to fix in software development and how we get there from here.

Comments

Reactive is an extension of event driven

[benjymouse]

As far as I can tell, this person (or persons) has discovered something that has a name already: Event-driven programming. It's been around for a very long time. It has many of the benefits of naive multi-threaded coding without the warts. But it introduces warts of its own, with event orderings being the big one.

What Erik Meijer discovered was that an event can be viewed as a sequence. Each occurrence of the event is an "item" of the sequence. What's why he wrote an article called "Your mouse is a database": The mouse is a sequence of multiple event types such as moves, buttons etc.

Once you start to view (and represent) events as "push" sequences interesting things start to happen: Suddenly you can *compose* events in the same way you compose collections/sequences.

Erik Meijer wrote the Active Extensions for .NET which does exactly that. Using LINQ you can transform, aggregate, group, partition, project/map, filter etc events.

Consider, for instance, stock market ticker values: Clearly you can see those as events: When a deal/offer it is an event. Multiple events is a stream/sequence. Now imagine you want to know each time a symbol has "peaked" - i.e. each time 3 consecutive values for any symbol has the maximum as the middle value. With Reactive Extensions and LINQ you would write:

var peaks = stockQuotes.GroupBy(sq => sq.Symbol).SelectMany(g => g.Buffer(3, 1).Where(IsPeak));

where IsPeak is defined as:

bool IsPeak(IList<Quote> b) {
        b[0].Rate < b[1].Rate && b[1].Rate > b[2].Rate;
}

Explanation:
1. stockQuotes is the IObservable stream of quotes.
2. GroupBy created a new stream of multiple streams. Each time a new symbol is encountered, a new group will be added (appear in the stream); if the symbol has already been encountered the quote is added to the end of the stream for the symbol.
3. Buffer creates a "sliding" buffers (increments of 1), each with 3 items.
4. Where filters the IObservable so that only "peaks" are let through.
5. SelectMany "flattens" multiple streams into a single stream again, i.e. creates a single stream of quotes regardless of their symbol (group)

Now, this is an IObservable stream with no subscribers (observers) yet. This also means that there is no subscription at stockQuotes. But as soon as you register a subscription like this:

                  peaks.Subscribe(Peaked)

It starts to invoke the Peaked method with peaks consisting of lists with exactly 3 items each. And this will go on and one.

Now imagine how you would write something like that using events and event handlers? It will probably take 10 times more code and be less readable than the above. (Yes, I know that it is not entirely straightforward if you are not used to RX and LINQ).