The term “reactive” is overused these days. However, it is fitting when talking about reactive programming. Below, we will look at this development model structured around data streams that are asynchronous.
Programming with Asynchronous Data Streams
The spine of your application will be data streams as you use reactive programming. The data stream will convey failures, calls, messages, and events. You observe the data streams with reactive programming and react when values are emitted.
Therefore, reactive programming is a cost-efficient way of organizing a project to create data streams in your code of just about anything from anything, including sensor measurements, cache events, variable changes, availability notifications, ingested messages, HTTP requests, and click events. Your application then becomes inherently asynchronous. The principles of reactive programming have been implemented by Reactive eXtension (RX) using observable sequences to compose event-based and asynchronous programs. Your code subscribes to and creates data streams with RX called observables.
What Are Cold Observables?
You need to evaluate the different observables (or data streams) that your program will deal with. The streams come in two classes: cold and hot. If you want to succeed with reactive programming, you must know the difference between the two.
Observables that are cold could be considered lazy. Only when someone starts observing them do they start to do anything. Only when they’re consumed do they begin running. So, cold observables represent asynchronous actions that will not be executed until someone wants the results. For instance, consider a file download. The cold stream will not begin pulling bytes if no one is interested in using the data. You get all of the data produced by the cold stream when you subscribe, and the items are not shared with all subscribers.
How Do Hot Streams Work?
Much like data sent by a user or sensor, such as a stock ticker, hot observables are active before you subscribe. The stream does not depend on a subscriber. An observer will get all of the observables emitted after they subscribe. All subscribers access the values. For instance, a thermometer will publish the current temperature measurement even if no one has subscribed to it. The subscriber receives the next measure automatically once they register to the observable. Knowing the difference between cold and hot observables will influence how your code consumes the streams.