Reactive programming is a programming style focused on building software applications that handle sequences of events over time. In other words, it deals with asynchronous data streams and reacts to changes dynamically.
This concept was introduced in 1997 and gained popularity with the creation of the Reactive Manifesto in 2014, which defines tenets for designing the architecture of reactive systems. This paradigm doesn't involve a control flow driven by a thread of execution. Instead, the application flow is driven by the availability of new information.
Reactive programming follows the Observer design pattern:
"The “listening” to the stream is called subscribing. The functions we are defining are observers. The stream is the observable being observed." Functional Reactive Programming - Streams on steroids (nexocode.com)
Reactive programming involves the following key concepts:
Data stream: The core element representing a sequence of events occurring over time from asynchronous operations, such as API calls.
Observable: The data stream model which is a reusable object used to manipulate data streams and subscribe to them at any given time.
Observer: The consumer reacts to data stream changes by subscribing to the associated observable object that handles the data stream lifecycle.
Operator: A higher-order function that manipulates and transforms data streams in multiple ways, like filtering and mapping.
Backpressure: It´s a concept that deals with situations when an observable emits data faster than the observer can process it. There are reactive mechanisms to handle these unwanted events, such as Buffering and Throttling.
To talk about reactive programming, it's crucial to refer to the four tenets of reactive systems outlined in the Reactive Manifesto:
Responsive: The system should respond promptly and quickly while providing consistent behaviour to handle problems effectively.
Resilient: In case of failure, the system must remain responsive and functional. This can be achieved through replication, containment, isolation, and delegation. The failure of one component must not bring down the entire system.
Elastic: The system stays responsive under varying workloads and responds to changes effectively by allocating the required resources to match the input rate.
Message Driven: "Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency." The Reactive Manifesto
Reactive programming is widely used in scenarios including real-time web applications, the Internet Of Things (IoT), and different areas such as microservices, distributed systems and GUI development.
The ReactiveX API is supported by popular programming languages such as JavaScript, Python, Java, C#, Scala, and more. Several languages also support reactive libraries to build applications: RxJS for Javascript, RxJava for Java, ReactiveSwift for Swift, and Reactive Extensions (RX) for .NET.
Reactive Programming also follows a declarative style that employs operators like filter, map, and combine to transform data streams and apply functional principles through function composition.
Keep in mind that this paradigm is not equivalent to multi-threaded programming:
"This confusion happens because while both reactive and threaded programming do things concurrently, threaded programming will also happen in parallel, whereas reactive programming doesn’t mean things are necessarily done in parallel." What is Reactive Programming? | VMware Tanzu Developer Center
What are the benefits of Reactive Programming:
Scalability: It appropriately manages asynchronous and event-driven workloads, making it suitable for handling high concurrency.
Responsiveness: As one of the tenets of reactive systems, applications react to new events as soon as they occur, providing an interactive and great real-time experience.
Performance: It provides better CPU usage as opposed to single-threaded execution because it has control over the time it takes to process and respond to events.
Error handling: It facilitates mechanisms for handling unexpected situations consistently. It is also highly testable due to the isolation of the business logic from the side effects.
And the drawbacks:
Debugging: The asynchronous nature of reactive programming makes it harder to trace the data flow and determine the system's state at a given time.
Memory consumption: Many data streams can be resource-intensive, and memory leaks can slow down the user experience if resources aren't used efficiently.
Learning Curve: Reactive concepts can be initially confusing and challenging to implement in various scenarios. It is also difficult for developers accustomed to imperative paradigms rather than declarative ones.
You can check out my video:
Comments