The rise of Reactive Programming

As a result, the complexity of software is increasing. Especially in e-commerce, where order systems and the back-end must connect perfectly, the (almost) real-time processing of huge amounts of data is increasingly becoming a requirement. Managing simultaneous changes between modules becomes a major challenge.

A trend within software engineering that responds to this is 'reactive programming'. Spilberg sees increasing demand for software developers familiar with this software architecture style. What is reactive programming, what are reactive streams, why is this way of thinking on the rise? And how does this declarative programming paradigm work?

Spilberg found Nicolas Fränkel, developer advocate at Hazelcast, willing to explain this new concept of programming. The Swiss consultant/trainer/author of books held a webinar with lots of 'practice'. He does not want to be a 'reactive' guru who only outlines the benefits and is blind to the limitations.

Instead of giving a long theoretical treatise, Fränkel demonstrated how reactive programming works in concrete terms. Developers could see step by step how he migrated an app to the 'reactive model'. In doing so, he chose a traditional Spring Boot application, an open source Java-based framework for microservices. Such a Spring Boot contains comprehensive infrastructure support. You can develop enterprise-ready applications with it.

Reactive programming is simply a programming concept or thinking pattern driven by events. Normally, these events occur in a certain sequence over time. This software architecture style deals with these data streams and revolves around the 'propagation' of changes. Data streams form the backbone of the application. Events, messages, calls and even failures are transmitted through a data stream.

In reactive programming, you observe these flows and react when a value is transmitted. Such a system reacts quickly, timely if possible. Another characteristic is resilience. Even if something goes wrong, responsiveness is maintained. Even with a sharply increasing workload, everything continues to work well. Last but not least, the system works according to the 'actor model' and is 'driven' by messages. This message flow is asynchronous. This development model is structured entirely around asynchronous data flows.

Side effect is that the application becomes asynchronous through and through. The purpose of 'reactive streams' is to provide a standard for processing asynchronous streams with non-blocking 'backpressure'.