An introduction to Reactive Programming with RxJava – Part #1

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 have a growing demand on how to handle an increasing amount of data, a massive 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. These changes have led to that a lot of different concepts, and design principals have popped up, where maybe Microservices are among those with the most buzz right now.

Reactive Programming has lately (well, since 2013) gained quite significant popularity driven by companies such as Netflix, Facebook, Microsoft and others. That resulted in frameworks such as Akka, Reactive Extensions in .NET, ReactiveObjC, RxJava and more. However, this is nothing new; some states that it already started to be 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 shared vocabulary for people to use when explaining a reactive system. The goals of a reactive architecture and reactive programming are to create an event-driven system, that can react to load and failures and remain a responsive system to the users. The following bullets are 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 based on events and that you have actors that can subscribe to specific events and act upon 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 changed 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). This after you have updated either A or B. The drawback of later is that the function C needs to know A and B, and A, B and C will 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 need to know much more about A and B.

A more realistic 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 given as a single event or message. 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 continue executing other logic until it gets an event as an answer. And first, when it receives a response it can start processing that event.

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

 

This blog entry is an updated version of the one publish on One Agency’s blog, https://www.oneagency.se/reactive-programming-with-rxjava/.


[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

Leave a Reply

Your email address will not be published. Required fields are marked *