This was written for my Tech Writing class where I had to explain the concept of reactive programming to a more general audience that might not have a background in computer science. Most programmers might find this explanation too vague or simplified.
The Need To Go Reactive
The computer industry today is progressively producing applications that operate at an ever-growing complexity. The rise of these new technologies challenge how code has been traditionally written and forces programmers to re-architect established modes of thinking in order to build a much cleaner and maintainable application. Reactive programming is a style of programming that addresses current issues in traditional programming styles by utilizing concepts such as asynchronous events (processes or events that are not coordinated but can happen at the same time). It allows a developer to explicitly model non-deterministic input seen in real-time applications (such as when a user clicks a mouse) as a stream of data that can interact with other streams of data within the system. This document will address the problems with how traditional programming functions, explain how reactive programming works, and then describe the use of it within modern applications.
Procedural's Problems
To understand just how conceptually different reactive programming is, it is important to have a mental model of how traditional procedural programming works. In the beginning, computers were made to receive a program, execute the program with a given input, and then provide output as the result of the execution. In procedural programming, a computational process is executed linearly, with each line of code executed right after another, just as the code was written. Procedural computation lends itself well to mathematical and business applications, where established formulas are required to run in a continuous straight line fashion. This method of doing things can be compared to grabbing a brick, walking up to the top of a building (program startup time), and then dropping the brick off the side of the building hoping that it hits the desired target (performs calculations) on the way down. A brick can fall quickly but a pigeon (other computation running at the same time) flying in its way might cause the brick to not hit its original target. Reactive programming abandons this linear way of thinking and allows the developers to model the unexpected pigeon to properly account for it.
What is Reactive Programming
Reactive programming can be thought of as rivers of computation where the streams of data coming through can interact with each other in a manner that results in new streams of data being created. Instead of dropping a brick, a stream’s contents flow and propagate through all other streams it is connected to through defined interactions. An example of one of these interactions is known as ‘zip’, where two streams of data are combined together as input flows in to create a new stream with the results of that combination. Zip will take two streams of data and, when it has received data from both of them, will combine them together and then emit it as its own stream, similar to when two rivers of water come together to make a new one.
The resulting zip stream can now have operations performed on itself to create even newer streams. An example of this is when stream A and B exist, both of which have been zipped to make stream C, then stream C has been zipped with stream D to make stream E. Now when stream A emits a new value from its stream, the change propagates up to C and then to E. This propagation of change is also called “emergent behavior” and is one of the reasons that this style of programming is so popular. It is important to note that zip is only one of many interactions that can be performed with streams. To fix the pigeon problem presented earlier, the pigeon and brick operations would be defined as streams and then combined by some interaction explicitly so the resulting behavior is expected. Without merging these two streams in some way, the pigeon could never interact with the brick. This explicit modeling of interaction is what allows interactive applications to be developed quickly and reliably.
Benefits of Reactive Programming
Developing applications become simplified when incorporating reactive programming by unifying all data being passed throughout the system under the one common “stream” concept. User input, data being received from the server, and computations being performed can just be thought of as streams that all can interact with one another in the same way as they could any other stream. Knowledge of what interactions can take place allows a developer to easily pick up a new piece of code from a totally different application and know exactly what to expect from a stream just by the operations it performs. An example application could have streams of input coming in from a server which are zipped together in a way that it can rendered on a screen to the user. These streams are very modular and end-to-end testing can be performed by simulating input on one end of the stream and checking for whether or not the proper data comes out on the other end of the stream.
Conclusion
The future for reactive programming is bright as it has been gaining popularity by multiple development communities over recent years. Angular, a popular web framework jointly developed by both Google and Microsoft, has incorporated reactive programming principles throughout itself. Netflix has switched to a reactive architecture in both their PS3 and Windows 8 applications (Jafar Husain 2013). Reactive programming is still relatively young compared to programming styles such as procedural, and there is room for improvement in the underlying stream implementation, as well as designing of said streams. Best practices for the programming style are still emerging almost daily, but it currently fixes issues of procedural programming because of how reactive programming works, allowing better applications to be written. The reactive programming style will continue to improve overtime as its large dedicated community continues to develop and fully realize its potential.
References
Husain, J. (2013, January 16). Reactive Programming at Netflix. Retrieved from http://techblog.netflix.com/2013/01/reactive-programming-at-netflix.html
Zip. (2014, December 15). [Graph explaining how when two streams zip together what the resulting data looks like]. ReactiveX Documentation. Retrieved from http://reactivex.io/documentation/operators/zip.html
