What is reactive programming Subscribe

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.

I'll get back to the theory later, but let's take a first look at a simple 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);

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 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.

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, as the compiler captures the surrounding state
  • 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
  • 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.
  • futures and promises - great interfaces to all asynchronous computations
  • messaging middleware (good old JMS+MDBs eh?)
  • async I/O , i.e. delegate to another library/subsystem
  • streams, react libraries - smarter implementations for producer/consumer protocols
  • etc

More reading

Continue this reactive programming series with Closures and reactive programming.

By: Razie | 2014-06-19 .. 2016-05-14 | Tags: post , reactive , javascript , raphael , js , programming , functional |

See more in: Cool Scala Subscribe

Viewed 4118 times ( | Print ) this page.

This content is Copyrighted, all rights reserved.

You need to log in to post a comment!