There has been a lot of buzz about reactive systems over the past couple of years. Along with the buzz comes the collection of relevant keyword salads like reactive streams, reactive extensions, reactive programming, functional reactive programming, etc. If you’ve been in the technology industry long enough, you’ve seen the cyclical ups and downs of buzzwords and acronyms from time to time. So, is all of that another soon-to-be-dated hype?
I’ve heard software engineers dismissing reactive systems as nothing more than an alias for asynchronous event-based systems, much like the way some dismiss microservices as SOA (service oriented architecture) less ESB (enterprise service bus). While technology buzzwords with reinvented meaning do oftentimes pop up, I see enough distinctive traits in reactive systems to think that the name isn’t simply another alias.
What are reactive systems?
The describes the essential characteristics of the reactive systems: responsive, resilient, elastic and message-driven. That gives a high-level picture and sounds a little generic. In particular, responsiveness, resilience, elasticity described in the manifesto are almost standard requirements of many real-world applications these days.
Perhaps “message-driven” is the requirement that truly differentiates reactive systems from others. Under the hood, a reactive system relies on interactions via asynchronous that establishes boundaries among individual components. Such an interaction model helps pave the path toward loose-coupling both time-wise and location-wise for concurrency and distributability, respectively. In addition, it allows the system to be integrally equipped with some non-blocking mechanism to regulate data flows (more on this below).
can be viewed as a specific type of reactive systems that centers around stream processing, expressing compositional streams as .
One of the non-blocking regulatory mechanisms mentioned earlier is . It may be the most sought-after functionality for systems that implement reactive streams. It’s an asynchronous feedback mechanism operating in the opposite direction of the stream towards the upstream components for load regulation.
With the built-in back-pressure regulating the stream flows in a non-blocking fashion, the system is able to operate with relatively more steady memory utilizations. Such functionality eliminates potentially devastating stack overflow problems (e.g. caused by a slow data sink) which would typically have to be countered by custom-building data buffering mechanism throughout the stream flows.
emphasizes formulating asynchronous programming logic as data streams, and automatic propagation of changes to values of correlated variables in the system. The languages used for such programming paradigm would provide suitable composable functions to operate on the formulated streams.
By design, reactive programming favors the style which expresses and resolves computational problems using composable functions. Nevertheless, the existence of the term predates this reactive “movement” by more than a decade. FRP has a vastly different focus and centers around using functions to express behaviors over continuous time with a simple denotation semantics. Yet, it’s now oftentimes viewed as reactive programming with an explicit emphasis in functional programming.
is an library targeted for building scalable concurrent and distributed applications on JVM (Java Virtual Machine). At its core are computational primitives called that maintain state and behavior, and communicate among themselves via asynchronous message-passing.
Written in Scala, Akka actors are by nature lightweight and loosely coupled. That, coupled with Akka’s robust routing, sharding, and pub-sub features for scalable distributed systems such as , make them a great platform for building reactive systems.
A front-runner (and a founding member) of the reactive streams initiative is . It’s built on top of Akka actors and provides an extensive set of APIs for building stream topologies and processing streams in a highly compositional fashion. A recent of mine centers around Akka streams and how it can be used to perform some basic text mining.
Apparently, Akka streams as a reactive initiative has been striving these days. Akka-Streams-based drivers such as and for RabbitMQ and MongoDB have started to gain some momentum in the technology industry. In addition, Akka HTTP, which is the next generation of the REST/HTTP toolkit, is also built to be stream-enabled with Akka streams as its underlying engine.
With the steadily growing momentum in adopting the reactive systems initiative, it apparently has surpassed the stage of being a mere hype. It’s also evidently more than an reinvented buzzword of asynchronous event-based systems. From a technical merits perspective, I see no reason why it won’t become more prominent. Nevertheless, even open-source technology initiatives are like commercial products — good timing can quickly attract attention in the initial stage and suitable marketing can help gain on-going momentum necessary to popularize to the broader user base.
Timing-wise, functional programming has been on the rise so I’d say it’s great timing, as the programming style is favorably embraced in building reactive systems. As to marketing, I believe more intuitive and revelatory naming of the initiative would sell better to the technology industry. One could hardly grasp anything meaningful when hearing the term “reactive systems” for the first time. Although the term “reactive” addresses some aspect of the embraced change propagation in such systems, it doesn’t jump out at the audience as a signature characteristic.
With reactive systems, reactive streams and reactive programming predominantly oriented around streams, I think the term “stream” is a more revelatory keyword than “reactive.” Trading generality with simplicity and intuition, I would combine reactive systems and reactive streams as a single initiative, and replace “reactive” with something that centers around “stream.”
This article is published as part of the IDG Contributor Network.