Technology Security Analyst
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.
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.
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.