fbpx Skip to content

An introduction to Reactive Programming with RxJava – Part #1

In the following two-part series I will explain the basics of Reactive Programming (pt. 1) and further give some practical examples by using the RxJava framework (pt. 2).

Today’s system and applications has a growing demand on how to handle a growing amount of data, a huge number of concurrent users, an up-time that should be almost 100% and at the same time have a quick and responsive system or UI. This has led to that a lot of different concepts and design principals has popped up, where maybe Microservices are among those with the most buzz right now.

Reactive Programming has lately (well, since 2013) gained quite big popularity driven by companies such as Netflix, Facebook, Microsoft and others. This has resulted in frameworks such as Akka, Reactive Extensions in .NET, ReactiveObjC, RxJava and more. However, this is really nothing new; some states that it was already discussed in the 70’s, but the first paper with the name ‘reactive’ in its title was “Functional Reactive Animation” from 1997[1]. Even though it is referring to Reactive Functional Programming, which is another concept, it’s still closely connected to Reactive Programming. RxJava, which we will look into in the second part, is building on the Observer/Observable pattern which has been in the JDK since version 1.0. This pattern was even described in the famous book “Design Patterns” by GOF[2].

Reactive Programming started to gain a lot of attraction when the Reactive Manifesto[3] was published in 2013 by Jonas Bonér, the purpose of this manifesto is to create a common vocabulary for people to use when explaining a reactive system. The goals of a reactive architecture and reactive programming is to create an event-driven system, that can react on load and failures and still remain a responsive system to the users. The following bullets are presented in the reactive manifesto:

  • React to events: the event-driven nature enables the following qualities
  • React to load: focus on scalability rather than single-user performance
  • React to failure: build resilient systems with the ability to recover at all levels
  • React to users: combine the above traits for an interactive user experience

In other words, a system that is Event-Driven, Scalable, Resilient and Interactive[4].

The idea of the concept is that everything that happens in a system is based on events and that you have actors that can subscribe on certain events and act up on them. A common metaphor is to use an excel sheet, where you can have two cells (A and B) with values and then a third cell (C) that is a function based on the content of the two other cells. The content of A and B can be updated at any time, but when you are updating either A or B then C is automatically updated.

In comparison with a non-reactive system (imperative system), you would have to specify that you want to run the function (C), after you have updated either A or B. The drawback of later is that the function C needs to have a knowledge of A and B, and that A, B and C would be tightly coupled. Where in the reactive system, C just needs to register that it’s interested in the update events of A and B, it doesn’t really need to know much more about A and B.

A more real example would be a web service that has a resource for getting users from a database. But instead of delivering them as a big blob of data, each user would be delivered as a single event or message. This would mean that the client could start parsing/displaying the user data, while the web service is still returning the remaining users.

So; what are the advantages of Reactive Programming compared to imperative programming? The main advantage is that the latter is using synchronous calls and is blocking, while the reactive one is asynchronous and non-blocking. That is, in imperative programming you usually call a method and then wait until you get a response. The application is blocked for this period and can’t do anything else. However, with Reactive Programming you call the method and then the application can continue until it gets an event as answer, and can then start processing that event.

This was a short introduction to the phenomena of reactive programming. Stay tuned for the next part (pt. 2) where we’ll look at some more concrete examples with RxJava.


Read pt #2, The Framework, here and pt #3, Convert a traditional web application to a reactive, here.


[1] http://conal.net/papers/icfp97/
[2] https://en.wikipedia.org/wiki/Design_Patterns
[3] http://www.reactivemanifesto.org/
[4] https://www.lightbend.com/blog/why_do_we_need_a_reactive_manifesto%3F