Reactive Frameworks 101: What they are and how they can help make your application better

Let’s start with what reactive frameworks are. To understand the term, we first split it into two components – reactive programming and reactive systems.

Reactive programming (Rx) is defined as an asynchronous programming model that deals with data streams, making it possible to easily express static (arrays for instance) or dynamic (e.g. event emitters) data streams through programming languages.

A reactive system on the other hand is an architectural style that enables applications made up of microservices to work together to better communicate with each other and their environment. They are event-driven, interactive, flexible, resilient, and responsive as they harness asynchronous message-driven communication. This architecture type is popular with more enterprises turning to the cloud.

Together, reactive systems and reactive programming create reactive frameworks.

Author of several programming books Bruce Eckel, and CTO of Typesafe Jonas Boner published “The Reactive Manifesto”, which explains that reactive applications need to be able to react to events (flexible), load (interactive), failure (resilient), and users (responsive).

Companies that have been using Rx extensively are Netflix and Google. Take Google Maps for instance. The app places a dot on your location, which moves with you by tracking your device’s position relative to North. It submits these values to the API every few seconds, which displays the response as the moving dot. That’s reactive programming in a nutshell.

As for Netflix, the digital streaming service receives hundreds of billions of requests every single day and needs to run all these “events” alongside each other to produce quick and reliable responses to consumer clicks. All possible because of reactive programming.

That brings us to Data Streams. What are they?

In reactive programming, all events are in the form of a data stream where information and data are pushed to the user. Reactive programming uses asynchronous non-blocking data streams. Asynchronous means you don’t have to wait for a task to be completed, you can move on to the next task until the data is available.

Every event comes from a data stream. That means any messages, calls, and even failures, are going to be conveyed as a result of the stream. In reactive programming, data streams are created from events that happen as a result of variables and data structures.

Data streams are in effect the foundation of your application. With Rx, you “observe” these data streams and react when it returns a value.

Which takes us next to Observables. What are they?

If the data stream is the foundation of reactive programming, observables are the building blocks.

An observable is a collection of data that waits to be invoked before it can issue data. There are two types of observables – those that require a subscription in the form of an action (cold) and those that do not (hot).

For instance, if there is a download available and the user clicks on the download button, it becomes a cold observable as nothing happens unless the user interacts with the stream. A new ticker that shows live updates even without any action by the user is a hot observable.

In reactive programming, every data stream is observable.

Here are some of the key advantages of this approach

Rx makes the backend interactive
Rx makes for faster systems as it becomes simpler to do asynchronous work
Rx makes it easier to compose data streams
Rx makes the code base more readable Rx increases the response time for consumers on account of its asynchronous nature
Rx makes the application more efficient

For greater productivity, better resilience, and greatly improved scalability, enterprises ought to consider a reactive framework as it embraces reactive programming and reactive systems to deliver a positive experience for users. If you would like to know more about how reactive programming can help your enterprise, do get in touch with us at CloudNow.

This blog originally published at CloudNow Blog. Link to the original blog