Reactive Programming with RxJava
Tagged as EN · book · review · java
Written on
RxJava is an implementation of “Reactive Extensions” (Rx) in Java. But what is this? Originally Rx are an implementation of Microsoft to address the increasing complexity of software. It is a model to build large scale asynchronous service architectures.
Another company that has to be mentioned is Netflix: they implemented the Rx in Java which resulted in RxJava.
On the programming side Rx looks very similar to how streams
(java.util.stream.Stream) work. The main difference in my opinion is that
streams are pull and lazy. They produce only as much data as someone is reading
from them. RxJava on the other side is more push style. The source of data is
pushing events through a pipe of operators similar to what you know from streams
(filter(), map(), and so on) to the sink. And as I know from this book, Java
streams are the wrong tool to parallelize anything that is not CPU bound–like
network requests. There reason for this is, that (parallel) streams are executed
on a thread pool that is shared with several other features of Java. This thread
pools is limited to have only that many workers as the system has CPU
cores. Therefore this pool gets exhausted very soon, when threads in it get
blocked by I/O operations. Any thread waiting for an I/O operation effectively
results in a processor core not used by your program.
RxJava on the other hand is not limited to a fixed thread pool. Any source
(Observable) and sink (Subscriber) of data can be bound declaratively to
user defined Schedulers. As well as Rx favours a model in which I/O
operations are done asynchronously and non-blocking. Therefore resulting in a
need for much fewer threads. In a traditional model of using one thread per
network connection, threads become very soon the first thing that limits
scalability.
What is really great about this book
The best part of this book for me were the reflections on Relational Database Access in chapter 5. While as a developer you might be tempted to convert everything to the reactive model, this part of the book shows where it doesn't make sense to do so.
By converting the access to your relational database to an asynchronous model you won't gain anything. Whatever you are doing on the client side, let's say for example your PostgreSQL will run all of your concurrent requests in different processes. This results in a noticeable limit on the number of parallel queries you're able to run. You cannot lift this limit by becoming asynchronous on the client side.
