A Brief History
Explore the history of RxJava from its roots in Microsoft's Reactive Extensions for .NET to its adoption by Netflix and evolution into an essential tool for reactive programming on Android. Understand how RxJava simplifies concurrent programming and why it became popular in event-driven environments like Android.
The origin
On October 28, 2005, Microsoft CTO, Ray Ozzie, wrote a 5000-word internal memo titled “The Internet Services Disruption.” The memo stressed to every department at Microsoft that they needed to adapt to the new Internet services era. With big players in the field like Google, Facebook, and Amazon, they needed to move fast.
Erik Meijer and the Cloud Programmability Team at Microsoft heeded that call. They were determined to alleviate the complexity that plagued these large systems and killed developer productivity. The team decided to work on a programming model that could be utilized for these data-intensive internet services.
Reactive extensions for .NET
The breakthrough occurred when they realized that by dualizing the Iterable interface from the Gang of Four’s Iterator pattern, they would have a nice push-based model for easily dealing with asynchronous data streams. Over the course of the next couple of years, they would refine this idea and create Rx. .Net (Reactive Extensions for .NET).
RxNET defined the set of interfaces—for example, IObservable, IObserver—that would be fundamental to reactive programming. Along with these came a toolbox of APIs for manipulating data streams such as mapping, filtering, selecting, transforming, and combining. Data streams had achieved first-class status with RxNET.
The birth of RxJava
One of the first users of this technology was Jafar Husain. When he left Microsoft and joined Netflix in 2011, he continued to advocate for Rx. Around that time, Netflix had successfully transitioned from a DVD rental service to an on-demand streaming service.
Heavy users traffic
By 2012, business was booming. Netflix would reach nearly 30 million subscribers by the end of the year. During this upward trajectory, the Netflix team realized that their servers were having a difficult time keeping up with the traffic.
One-size-fits-all
The problem was not simply in the sheer number of streaming subscribers, but also in the myriad devices that Netflix supported. There were set-top boxes, smart TVs, game consoles, desktop computers, and mobile devices. Each device had its own distinct UI and UX dictated by things like screen size, network bandwidth, input controls, and platform requirements.
Netflix, at the time, had a generic, one-size-fits-all API for these clients to query. This meant that clients would often have to issue multiple queries to get all the required data and then piece them together to fit their particular UI. This process was not only complex and slow on the client-side, but it resulted in a lot of extra load on the server.
The client teams
Ben Christensen, an engineer at Netflix, and his team decided to overhaul the Netflix API server architecture to decrease chattiness, increase performance, and allow for scalability.
They wanted their server API to be a “platform” for APIs and then handed over the reins of implementing those APIs to the client teams. By having each client team develop their own custom endpoints, the clients could consolidate multiple calls into a single call and get the exact data they needed. This eliminated the latency of multiple network calls on the client and the load on the server.
However, the client teams were not expert server developers, and writing server APIs is not a trivial exercise. Performant servers usually need to utilize multiple threads to service simultaneous requests and issue concurrent requests to back-end services and databases. The problem is that concurrent programming is difficult. The server team needed to make the process as simple and error-proof as possible for the client teams.
Finally RxJava
Luckily, Jafar Husain was there to boast of the merits of Rx to Ben Christensen, who realized it was a great approach to address all of the problems mentioned above. Reactive programming abstracts threading away so that developers do not have to be experts in writing concurrent programs.
Because the Netflix APIs were implemented in Java, they began to port the Reactive Extensions to Java. They called it RxJava, and in Netflix-fashion, they open-sourced it. They stayed as close to the RxNET implementation as possible while adjusting naming conventions and idioms to suit the Java programming language. In February 2013, Christensen and Husain announced RxJava to the world in a Netflix TechBlog post.
Reactive on Android
Even though RxJava started with Netflix servers, it found its way across the tech stack and across the industry. From back-ends to front-ends, web services to mobile clients, anything event-driven was a good candidate to receive a reactive makeover.
While making its way across the stack, Rx also made its way across programming languages. Ports to other languages were worked on as open-source projects under an umbrella project called ReactiveX. Reactive extensions were implemented for just about all the popular programming languages you could imagine: C++, Scala, Ruby, Python, Go, Groovy, Kotlin, PHP, and Swift, for example. There are even extensions for various frameworks such as RxCocoa and RxAndroid (the latter of which we’ll discuss in this course).
Why is RxJava popular in the Android world?
The event-driven nature of Android made it an ideal platform for reactive programming. Android developers must constantly deal with dynamic events in a responsive manner while making sure not to block the UI thread. Existing constructs like AsyncTask are both verbose and inadequate, so RxJava’s popularity in the Android world is no fluke.
Reactive manifesto
Another contributor to the jump in popularity for reactive programming was the Reactive Manifesto. This was a document written by Jonas Bonér, Dave Farley, Roland Kuhn, and Martin Thompson in 2013, and later updated in 2014. The manifesto argued that our present day’s demand for increasing amounts of data and faster response times required new and reactive software architecture. They defined a Reactive System to be one that is “Responsive, Resilient, Elastic, and Message-Driven.”
To date, thousands of people have signed the document. However, we leave the Reactive Manifesto here as an aside in this course since it only looks at reactive programming from a 10,000-foot view rather than really discussing how to accomplish it.