Foreword
This book, Rx.NET in Action, does a great job in explaining the details and background that .NET developers need to effectively use Rx. In particular, it explains how to connect the plethora of asynchronous types in .NET to Rx observables, and how to deal with errors, resource allocation, and last but not least, concurrency.
Since its inception, the .NET Framework has emphasized the importance of asynchronous execution and nonblocking I/O. Through delegates, the .NET Framework has emphasized higher-order functional programming from the beginning, and by automatically defining the BeginInvoke and EndInvoke methods on delegates, developers may call any method asynchronously.
But the BeginInvoke/EndInvoke pattern for asynchronous operations is tedious and verbose, because it requires converting your code into continuation-passing style. As an alternative, the .NET Framework introduced the event-based asynchronous pattern that uses the built-in support of .NET for events and event handlers. Although the event-based pattern was a big step forward compared to asynchronous delegates, more opportunities remained to streamline the development experience.
For synchronous streams of values, modeled by the standard interfaces of Enumerable/IEnumerator, the LINQ standard query operators provide a beautiful and elegant algebra for processing streams in a high-level and declarative manner. Wouldnt it be nice if we could use the fact that events are conceptually also streams of values and hence provide a similar LINQ-based programming model for events?
Another disadvantage of using events for asynchronous calls is that this ignores the fact that unlike most other events, such as mouse clicks, the events wired up to asynchronous operations produce at most one value. Wouldnt it be nice if we could use the fact that asynchronous methods return only a single value and hence provide a similar imperative programming model that supports regular control-flow-like conditionals, loops, and exception handling for asynchronous methods?
As it turns out, the answer to both questions is a resounding yes! By using the mathematical trick of equalization, we can mechanically convert the IEnumerable/IEnumerator interfaces for synchronous pull-based streams into the monadic IObservable/IObserver interfaces for asynchronous push-based streams. The async/await syntax in C# and Visual Basic allows developers to use regular imperative syntax to write both synchronous and asynchronous methods, and the LINQ query comprehensions allow developers to write queries over both synchronous and asynchronous data streams
This is the heart of Rx. Many languages outside the .NET world have now adopted the magic square of one/many sync/async, making developers happy and productive no matter what language theyre using.
If youre a .NET developer, youll want to keep a copy of this book handy to put Rx.NET into action!
E RIK M EIJER
I NVENTOR OF R X, FOUNDER OF A PPLIED D UALITY
Preface
Reactive Extensions (Rx) for .NET was first published in November 2009 under the short description Rx is a .NET Library that allows programmers to write succinct declarative code to orchestrate and coordinate asynchronous and event-based programs based on familiar .NET idioms and patterns. (See http://mng.bz/gQ31.)
I remember watching the first examples and reading the discussions. I was amazed by the elegance of the solutions and how simple they looked. Unfortunately, when I sat down and tried to use Rx, things were harder than I thought, and the mental change I needed to make toward reactive programming was significant. In those days, there wasnt a lot of material on the subject, and I had to struggle to solve my issues and learn things the hard way with a lot of trial and error.
In 2012, at end of my military service and upon joining CodeValue (www.codevalue.net), I had two major projects that enabled me to really appreciate my Rx knowledge. The first was about a cybersecurity application that needed to react to multiple events and coordinate them in order to show the end user the state of various incidents all happening in parallel. The second was a video chat application, running on mobile and PC devices. The video chat application reacted to events such as users logging in and out of the system and receiving messages of various types that had to be dealt with differently. Though these two systems were different, they shared the same problems of writing a flow based on eventsa flow that involves filtering of received values, dealing with asynchronicity and concurrency, and identifying patterns of recurring events so that the application could respond efficiently and correctly. I introduced Rx to both of those systems, and it was one of the things that made each a success. We exceeded expectations and preceded our schedule.
Still, even though I had knowledge of Rx, problems still happened from time to time, and little material on Rx, such as books and guides, was available. Many times problems originated because of my colleagues lack of knowledge or situations that were new to us. Luckily, after I identified the problem source, it would be easy to fix, mostly because of the flexibility of Rx operators. In the following years, I started to blog and speak about Rx and how it made solving complex problems easy. That is when the idea for this book started to grow. My vision was to create a step-by-step guide that holds the pieces needed for the .NET programmer to get the maximum out of the Rx library and the reactive programming paradigm. I also wanted to write about the practices that I acquired over the years, as well as the pitfalls and their solutions.