What’s in a Name: Reactive

Geeks tend to be quite liberal with names: We often overload one word with different things or concepts. Maybe that’s because our teachers tormented us with operator overloading .

Recently, I heard somebody say “what a damned reactive systems this is”. Before I could ask her what she meant by this, she vanished in a puff of pure logic. So I tried to find out myself, and encountered a severe case of ambiguity (semantic overloading).

Let me share some of my results with you.

To React

The word is of Latin origin: re (in return) agere (to do, to act): Act in return or response to something, i.e., something happens and you act accordingly.

In reality, this kind of reaction to any event can be immediate or deferred, the term itself does not imply any particular performance or timing constraint.

Reactive as a Synonym for “Responsive”

Reactive is sometimes used instead of the term responsive to describe the temporal behavior of user interfaces: If the UI reacts or responds quickly to user input, we sometimes (inaccurately) call the whole system reactive. If you want to be precise you will surely use responsive.

Reactive as a Synonom for “Shows Reaction”

Just in case you’re older than 50 - you might remember the times when (relational) database systems came up with triggers. At first, many people believed them to be incredibly cool stuff. But the cleverer gang quickly found out that they (the triggers) were the ‘goto’ of relational algebra - and should therefore be avoided whereever possible.

But let’s get back to reactivity. Database triggers can react to numerous things: Certain attributes exceeding certain values, certain condtitions becoming true. Triggers would then initiate predefined actions, therefore re-act (or respond) to certain situations or events.

Thus, we have to acknowledge that systems build with database triggers are in this sense reactive systems.

Reactive as in “Your Favorite Spreadsheet”

Imagine your favorite spreadsheet application (just in case you favor such types of software). If you don’t like spreadsheets, just think of a beautiful implementation of the Model-View-Controller pattern.

Spreadsheet as Example of Reactivity
Spreadsheet as Example of Reactivity

Cell B42 contains the formula “=A42*A42” and is re-evaluated every time A42 changes. Even better: When changing the value of the cell “A42” in the example spreadsheet, all other cells referring to A42 in their formulae will immediately update accordingly. Since immediately means quickly, and you might righty consider this behavior to be “reactive”.

Reactive as in “Data Binding”

This spreadsheet is a special case of the general concept of data binding.
Take your car, for example: The speedometer is bound to a formula similar to

currentSpeed = nrOfTireRevolutionsPerSecond * tireSize * 3.1415 * magicCorrection

This formula is evaluated as long as the car functions - for many cars even when the ignition is turned off …

Often, we want this kind of behavior in graphical user interfaces: Like your speedometer, a UI widget should reflect the current state of some variable, sensor, or information.

Let’s say you’re the owner of the famous half-eaten-cookies online store – surely, you would want a “business dashboard” with your latest sales reports that changes automatically:

Business dashboard as example of reactivity

This is completely different from the usual interpretation in any imperative programming language, where the statement is executed, the variable (e.g. currentSpeed) is set and execution moves on.

GUI frameworks have gone a long way to make data binding convenient – but still it’s often a nuisance for developers.

Reactive as in “The Reactive Manifesto”

Manifestos of all kind are now filling more and more public sites. A recent one (from September 2014) is “The Reactive Manifesto”, and it proclaims no less than a completely new class of software systems (which, in my humble opinion, is vastly exaggerated, but that’s a different story):

The Reactive Manifesto names the following characteristics of reactive systems:

  1. Responsive
  2. Resilient
  3. Elastic
  4. Message Driven

(Hairsplitting friends would surely call items 1–3 requirements and item 4 a solution approach, but let’s leave the nitpicking aside for the moment).

Prime idea behind this manifesto is to bring async messaging to a micro-level. In systems based upon Akka and Vert.x you’ll see this in action. Prior to the reactive manifesto, async was more or less limited to a macroscopic or global level within software architectures.

Reactive as in “Reactive Programming”

Reactive programming (RP) means programming with asynchronous data streams. Such data streams are nothing new or special: users clicking on buttons, customers arriving at our website, messages arriving through our good ol' messaging infrastructure.

RP makes asynchronous streams a first-class citizen, and thus gives you the tools to create, filter, order and manipulate them.

To be a little more precise: A stream is a sequence of events ordered in time that can emit one of the following three “things” (items, results):

  1. a value of an arbitrary type
  2. an error
  3. a finished signal, meaning: this stream has come to an end.

stream example
(Original idea for this diagram from Intro to Reactive Programming)

Reactive as in “Reactive Extensions” (Rx)

Let me try to describe RX as short as possible, relative to normal imperative programming:

In any normal (syncronous) call you write something like:

result = target.someFunction( param )

and get result as a return value. If someFunction is a long-running computation, that call might block your application.

With reactive extensions (or ReactiveX) you write more code and often don’t immediately get a result back, but an Observable, which you can query for its current state. The positive consequence: it does not block your application:

Observable.just("Hello, world!")
    .subscribe(s -> System.out.println(s));

In short: An Observable emits items which a Subscriber can query and process. For a more detailed introduction, I recommend Dan Lew’s Grokking RxJava. Dan explains the Observable and Subscriber patterns of Rx with simple code examples.

Reactive as in “Functional Reactive Programming”

ELM is a language created for functional reactive programming. It centers around signals, which are values that change over time. Examples include the cursor-position on your screen, the size of your browser windows, or the state of long-running computations.

Here’s one small example from the ELM distribution:

import Graphics.Element exposing (..)
import Mouse

main : Signal Element
main = Signal.map show Mouse.position

When compiled, it will display the mouse position - and update when you move the mouse around. Nothing spectacular, but old-school Java developers will surely wonder where the necessary loop has gone… welcome to Signals.

Reactive as in “Meteor is Reactive”

Meteor is a JavaScript based framework for interactive web applications.

Disclaimer: I’m deeply impressed by the Meteor framework and the activities around it (they got >10 Million VC money from nobody less than Netscape-founder Mark Andreesen… reason enough to have a closer look.)

(Stefan Tilkov’s comment on this post was that “having somebody throw money at something does not necessarily make it good…”)

In the Meteor universe (which is expanding with incredible velocity these days), reactivity means:

all the changes are reflected reactively on all connected browsers.

Meteor has taken data binding (see above) to the next level: It binds UI elements on arbitrary clients to database content on the server, making it possible to update large numbers of clients in near-real-time, when the subscribed data changes.

Meteor reactivy means you don’t have to bother with a DOM tree to reflect changes, instead you declare subscriptions - and the Meteor framework will update all associated clients automagically (via Websockets and their own tiny data-direct protocol).

Summary

Think twice (or more often) before using the term reactive: It’s not as specific as your favorite website might suggest. Different and valid interpretations exist. Whether someone means data binding, observables, responsiveness or event processing, all might somehow be related to reactive in one way or the other.

May events be with you!

Sources and Further References

And, just in case you have the chance to visit Java-Forum Stuttgart:

Meteor

Although Meteor is relatively new, a plethora of information, tutorials, examples already exist.

Acknowledgments

Thanx to Stefan Tilkov for commenting on a very early draft, and to Tobias Neef (expert on all things reactive) for very constructive comments and enhancements.

TAGS