An overview: Reactive Programming

What is reactive programming?

Reactive programming describes a design paradigm that relies on asynchronous programming logic to handle real-time updates to otherwise static content. It provides an efficient means -- the use of automated data streams -- to handle data updates to content whenever a user makes an inquiry.

Data streams used in reactive programming are coherent, cohesive collections of digital signals created on a continual or near-continual basis.

How does reactive programming work?

Reactive programming is all about streams, which are time-ordered sequences of related event messages. A given stream will generally start with an observer, which can be either a segment of code inside an application that watches for some condition related to the application, or a device like an IoT sensor that generates an event. A stream is sometimes diagrammed as an arrow -- left to right -- that starts with the observer process and flows through one or more handlers until it's completely processed, terminates in an error status, or forks into derivative streams. Reactive programming is about building those observers and handlers and threading the stream as required.

Device-generated streams are easily understood. But streams generated by software-inserted observers are a bit more complicated. Normally, these elements work either in cooperation with the processing work done by an application or they run periodically to monitor a database element. When this software element recognizes a condition, it generates an event in the stream.

An event stream is steered either by the handlers themselves where work is dispatched to a specific next process, or by a message bus such as an enterprise service bus or message queue that carries the message to designated bus listeners. The message handling process determines whether a message is broadcast to multiple handlers or to a single handler, and it would also normally be responsible for load-balancing among multiple parallel handlers or providing spare handlers in the case of a failure.

Each handler must either pass the message along, determine that the stream process has ended and "eat" the message, or generate an error. The handler may decide whether to "fork" a message to multiple streams or to generate a new stream or streams. These fork conditions are often used to separate tasks in message handling; a message might generate a local response to open a gate as well as a message to a transaction processing system.

Advantages of Reactive Programming

• Improves user experience: The asynchronous nature of RP means that whatever you program with it will offer a smoother, more responsive product for your users to interact with.
• Simple to compose streams of data: Reactive programming provide the potential for developers to create, filter, and combine streams of data which can emit a value, error, and a completed signal, to achieve powerful objectives.
• A lot simpler to do async/threaded work: The method that PR allows you to work on the data streams causes it becomes less hassle than regular threading.
• Avoid “callback hell” or "pyramid of doom": Callback Hell is an anti-pattern seen in code of asynchronous programming. It is a slang term used to describe and unwieldy number of nested “if” statements or functions. It usually happens when there are a lot of callback functions in the code. Developers can avoid the callback hell with reactive programming because it depends on asynchronous data streams.
• High performance in cooperation with Java: RP allows Java apps to have higher performance with lower memory requirements. This is made possible by avoiding blocking calls that lead to a process as well as context switches in the OS.

Disadvantages of Reactive Programming

• Hard to learn: RP have a reputation of being difficult since it is entirely different compared with previous ways of working. This leads to a steep learning curve when you start using it which may be a shock to some developers.
• More memory intensive: Applications will tend to be more memory intensive due to reactive programming relies on streams over time. This can lead to memory leakage which could end up seriously slowing things down for users.

Conclusion

And that brings us to the end of this course! I hope you’ve learned a lot about RxJS and reactive programming. I also hope you’ll keep practicing and coding with RxJS and reactive programming. I’ve added some links below for further reading.