Over the past few years, I've worked a lot with frontend architecture, analytics processing and asynchronous services.
As I've done that, one of the things that keeps catching my eye, is Reactive Programming.
I kept seeing mention of it everywhere and you might be wondering, like I was:
What is Reactive Programming?
A Data-Centered Paradigm
Reactive programming is, by-and-large, a paradigm created to face the challenges of modern-day data driven applications.
It is an attempt to more easily create highly interactive, low-latency, and constantly updating applications.
Before we talk about how Reactive Programming differs from the other programming paradigms that came before it, let's talk about those paradigms a little bit.
The Synchronous Paradigm
The Synchronous paradigm is the paradigm that most people are familiar with. The reason for that is that it's a great paradigm to start any application with.
In this paradigm, one event happens right after the other. Each event is executed in order and no two events can happen at the same time.
Synchronous code is often written as though it's organized by a single agent.
This agent might be the programmer in the case of a script.
The agent might be a controller in the case of an API.
The agent might be a model in the case of manipulating data.
What makes the synchronous paradigm so powerful is that it's really easy to follow and understand what an application is doing.
You can look through all of the lines of code and see what executed and what it did.
When any bugs occur, they're often easy to find and even easier to fix!
The Asynchronous Paradigm
As an application grows and user experience gets more complicated and data processing gets more intensive, people often start to look for a more efficient solution to their problems.
People often find that asynchronous programming is a solution to those problems.
In the asynchronous paradigm, two events can happen at the same time or in an unpredictable order.
When working with user experience you're able to put things on a background thread and not interrupt the flow of the user.
When working with data processing you're able to process two pieces of data simultaneously and that ends up with a much faster processing application.
This comes with a tradeoff, however.
Asynchronous programming is a lot harder to read than synchronous programming.
If you don't need the efficiency or the parallel processing it can make your applications much harder to debug. Especially when working on a team.
It can also create problems that were impossible before - like one piece of data being modified simultaneously by two separate threads of your application.
The Reactive Paradigm
As we get to more and more asynchronous processing the application gets closer and closer to using Reactive Programming.
Reactive programming is a subset of asynchronous processing that treats data in a very special way.
Reactive programming focuses on the data itself. How the data changes over time.
Instead of thinking of the code as the agent of change in an application, Reactive Programming thinks of data as the agent of change.
The code's only responsibility is to listen to changes in the data and do something in response to them. Reacting to the changes in the data.
The user is a data source and the application is a medium through which the data moves. The backend database is also a data source and the application is still only a medium through which it moves.
The reason this is a useful way of thinking of complex problems in software engineering is that it really gets rid of the illusion of control.
By writing an application in such a way that the user is the clear agent of change, it makes it so the application can much more readily respond to the needs of the user.
In writing our methods in such a way that we have no control over where the data comes from, we prevent ourselves from building brittle dependencies between methods.
Without these dependencies we can build applications that are much more ready to be run in an asynchronous manner without having a lot of the complexities that creates.
Reactive programming is, of course, not a silver bullet.
It is most applicable when you have large datasets, or constantly changing datasets, or infinite datasets like user click events in an application.
It can still be much harder to follow than its synchronous counterparts.
But, it does have an event log that you can look through when debugging applications.
Reactive Programming is an option to think about whenever you have an application where the data is front-and-center or the user interactions are front-and-center of the needs of the application.
Stream Processing and Reactive Programming
You might be able to see why Reactive Programming is so inter-twined with Stream Processing.
Streams, after all, are just a series of events ordered through time.
Reactive Programming happens to be a very effective way of thinking of Stream Processing problems.
Streams also happen to be a very effective way of thinking of underlying data sources when implementing Reactive Programming.
The two are very closely connected. But they are not synonymous with one another.
So, if you use them as synonyms, people might get confused.
Thanks for watching!
I hope this video has given you a good idea of what Reactive Programming is and how you can use it in your applications.
If you'd like to support the creation of more videos like this, check out the Patreon link below:
Thanks for watching!