Is RX Java something a server-side engineer needs?

Question

I can see that RX is good for Android and for UI event handling. I'm struggling to see what benefits RX provides on the back-end.

Was RX Java designed for back-end processing, or has this concept been taken too far?

Answer 1

Actually, RxJava was firstly implemented to tackle server-side problems. Reactive extensions originated from .NET world and were ported to Java for their back-end by Netflix. RxJava became a thing on server-side Java programming years before adoption on Android.

Back then, asynchronous and non-blocking processing proved to greatly enhance server performance. One could use callbacks to achieve this, but callbacks doesn't compose well and lead to callback hell. RxJava with it's functional call chaining style offered a (good) solution and started to see adoption.

Then it spread to Android to deal with network calls or UI events. While I use and enjoy it on Android, I always found RxJava to be less at home in Android than in server. Because of the general design conceptually closer from other servers technologies IMHO, even if I know reactive extensions were used on client side from the beginning in .NET world. But also because RxJava usage in Android have it's flaw. You could easily leak Context if you don't track your subscriptions. And you have to add .observeOn(AndroidSchedulers.mainThread()) nearly everywhere, that you forget from time to time and lead to crash. I bet it's the reasons who lead Android team to have their own take on the Observer pattern with Livedata on Architecture components.

Besides solving callback hell, RxJava offer to developer:

• The observer pattern: this pattern is great to expose data to other modules. It give a contract between producer and consumer, with a defined and standard behavior, handling of termination and way of controlling producer to the consumer (unsubscription, back pressure). Of course you don't need RxJava to implement this pattern but RxJava take it to another level.
• Error handling: in asynchronous system, error handling is tricky.
• A complete set of operators: more than hundred operators to transform, filter and combine streams. When you have data manipulation to perform, and usually back-end revolve around it, RxJava boil down your code to a few standard, explicit operators.

All in one, RxJava is a great fit for back-end processing, even more than in Android IMHO. You could find more on why Netflix implemented reactive extensions in Java and what where the benefits for their back-end here.

As of saying if it's needed for a server-side engineer, I would say it's not required but knowing it would greatly enhance your toolbox. Nowadays the trend is more and more asynchronous, with more and more middle-ware, libraries and framework offering only asynchronous API. Couchbase Java database API is based on RxJava for example. Plus reactive extension are not only Java, you will be able to leverage this knowledge in most languages.