Reactive Programming, thinking in Flows

One of the biggest differences between the pieces of your applications applying the “Reactive Programming” paradigm, and those with “Regular Programming” is the fact that your code is based on streams of information. This might be a bit tricky to get your head around first, because as a developer you’re used to one part of your application “moving” at the same time. You’re either loading data from the database, or doing some calculations for a report, or using a library to actually generate that report.

When it comes to the parts where you apply reactive programming however, different rules apply. Because of the asynchronous, event-driven streams inside your application, different parts can move at a different time. Compare it to a single robot, versus an entire factory. The one robot can process one part at a time, whereas in a factory, you have a whole range of different machines processing things at the same time.

Of course this implies that your application, and processes have to be able to actually support that concept. In case you need aggregates of your information (like the total sum of a number of elements) when all the elements aren’t processed yet, you’ll have to resort to blocking your flows, which of course results in your flows not being reactive anymore. Instead, you can resort to techniques like recalculating the average when more data flows in. Of course this greatly supports the name “Flux”. A Flux in Project Reactor is a datatype that will give you a list of data in an asynchonrous way. This can mean a range of different elements, but it can also means a single value varying through time, effectively giving it literally an extra dimension. This shows how Reactive Programming leans far closer to applications that have data “living” in this fourth dimension, like (nearly) real-time systems such as stock exchange tickers, concert ticket vendors, etc.

Ultimately, nothing stops you from applying multiple paradigms inside your application, applying both non-reactive parts (where you absolutely require transactions, etc) and reactive parts (more oriented towards real-time data streaming) to give your users “best of both worlds”.