What is reactive programming

What is reactive programming Subscribe Pub Share

Reactive programming is just that: instead of writing your program as a "synchronous" sequence of steps, you build your program in pieces that react to certain events, all decoupled asynchronously. You would not be wrong to think of them as callbacks.

Let's take a first look at a simple and basic demonstration of what reactive programming is, one that you can play with in the browser. I will be using Javascript instead of scala for this quick one!

Let's draw a ball and try to move it back and forth... or rather forth and back. We create a circle c and an animation a and then animate the circle (click Run to see it run:

No problem, all nice and dandy, until you try to move it back (c1 animation will move it forward and a2 supposedly brings it back):

Opa - now you realize that Raphael is way smarter than it looked and it actually does the animations on different threads or something. What happened is that we asked Raphael to move it forward and while it did start that action on a separate thread somehow, we immediately asked it to move it back... so the ball never got a chance to move...

That is exactly what happens with asynchronous I/O: the actual operations are delegated out to "someone else" and our execution context is free to do something else, not having to wait.

So... how do we move the ball back?

Wait for it?

var c = r.circle(20, 20, 10).attr("fill", "red")
var a1 = Raphael.animation({cx: 200, cy: 20}, 1000);
var a2 = Raphael.animation({cx: 20, cy: 20}, 1000);
c.animate(a1);
wait(1000);
c.animate(a2);

This is such a terrible idea that it's actually not possible in browser-side Javascript!

Instead, we can ask Raphael to do something else when it's done with the first animation:

There there, now we have a function (or rather a closure) moveItBack which reacts to the finish of the first animation... meanwhile, our little game code goes on to paint the blue ball and track enemies and stuff. This is familiar to anyone that has done some AJAX or node.js

In this case, we packed the continuation, the state of the computation into a callback closure, but it could have been an explicit message as well, in case of actors. A more decoupled example would have been to have the animation raise an event at the end, on a central "bus" which we listen to, and on that event do our continuation.

Real world reactive

While games are certainly hacker paradise, real world offers a lot more use for asynchronous programming, i.e. reactive. Instead of moving a red ball back and forth, think about waiting for a database query and doing something with the reply.

Or how about calling another REST service and waiting for the reply. Or... what about calling a few REST services in parallel and collecting and aggregating the results reactively? Cool, huh? Or how about a REST services that streams results back one by one and we process them as they're available (Stream, Observable)?

There are many ways to implement reactive, depending on the language and environment (JVM etc) you're using:

functions and closures - very useful to capture the context available at the time the sequence of events was initiated - excellent for creating callbacks and continuations, as the compiler captures the surrounding state in the closure
continuations - fancy construct to capture the state of the computation, somewhat similar to closures but this works inside regular statements
threads - it's not fun if we just wait for it, right? So let someone else do it... in the end, everything does happen inside someone's thread. We can use threads directly or indirectly through actors or such, but the simple fact that two things occur asynchronously implies two threads, even if one of them is in another process or driver.
setjmp/longjmp - related to continuations and coroutines below, a low level construct to capture the state of a computation (stack) in C.
coroutines (yield/next) - basic cooperative multi-tasking
actors - messaging/asynchronous processing constructs. Sometimes called processes, they have a queue of messages, processed in sequence on a single thread.
futures and promises - more abstract interfaces to all asynchronous computations
messaging middleware (good old JMS+MDBs eh?) - decoupled asynchronous processing within a distributed system, generally based on queues and topics with senders and receivers.
async I/O , i.e. delegate to another library/subsystem/driver
streams - smarter implementations for producer/consumer protocols, using an event/callback mechanism to process elements and quasi-standardized signaling to implement features like backpressure (i.e. have the sender knowingly back-off when the receiver is overwhelmed).
etc

DSL

Domain Specific Languages

Reactive

Reactive and asynchronous.

Play

The Play Framework.