Reactive programming is all the rage at Fluent 2016

Reactive programming, along with a great deal of advocacy for integrating the Observable design pattern into reactive architectures, was all the rage at the O'Reilly Fluent 2016 conference in San Francisco. This approach is ideal for implementing user interfaces, since it simplifies the abstractions around propagating change through an application. This means less work on coding responsive user interfaces for developers. In addition, it makes it easier to take advantage of various optimizations in browsers and native mobile devices.

There is, of course, Facebook's aptly named React JavaScript library, in addition to Google's AngularJS, and Microsoft's ReactiveX API. Microsoft's approach was designed to make it easier to leverage ideas from the Observer pattern, the Iterator pattern and functional programming. Matthew Podwysocki, principal software engineer at Microsoft, explained how Observables promise to improve event passing and state management for building better systems.

Think of data as streams

Many modern applications take advantage of game-programming principles to improve the UI. These applications are developed with a focus on building and responding to events, and dealing with delays in events. Podwysocki said developers need to think about data sets as streams. Games, such as Mario Brothers, drag and drop widgets, and data analytics are all just managed with streams.

Microsoft has been working on Reactive Extensions, or ReactiveX, since 2009. The idea was to create a framework for building data structures as something that objects could query against. The goal was to improve the development of asynchronous events. This is a challenge in JavaScript owing to its single threaded nature. Podwysocki said this can lead to callback hell, because developers are nesting callbacks on callback, and also because they are creating complex machines inside of them.

Avoid broken promises

For example, there are three disparate handlers for MouseUp, MouseDown and MouseMove. This puts the burden on developers to order the events, add event listeners and remove them, as well. Promises have been touted as one promising abstraction for dealing with this issue. But, as one Netflix engineer told TheServerSide, "Broken promises lead to broken applications."

More work needs to be done to make promises work consistently in order to be more widely adopted. "Cancellation is not part of a promise today," Podwysocki said. "Service workers don't have a notion of cancelling. We need some cleanup, and there is none in the spec."

Podwysocki provided some insight on addressing this problem, with a type-ahead search algorithm. The basic notion is to improve the recommendations provided to a user when they begin typing in a search string in an application. Users don't want to type much, and it is important to prioritize data they have previously requested. Developers should look at using events for value chains. For example, in the type-ahead search, the method can listen for user input without coding a subscription, because the asynchronous piping is built in.

It is important to create higher-level abstractions to deal with common use cases. For example, ReactiveX is not implementing abstractions like MouseDrag, which bundles lower-level events -- such as MouseDown, MouseMove and MouseUp -- into a single loop. This makes it possible to write a jQuery function in eight lines of code, rather than 30. This embraces the idea of creating higher-order abstractions that respond to user events and application load. These abstractions also have to react to failures in a graceful way.

Use Observables to link Iterator and Observer patterns

These ideas build upon the elements of reusable object-oriented software design patterns spelled out by the Gang of Four in 1994. Podwysocki was not sure why the Iterator and Observer design pattern were not connected. "What is the difference between iterable objects and events?" he asked. "I submit that they are not different."

Today, developers work with the Iterator and the Subject/Observer pattern using DOM. Podwysocki said he believes the Observable is the Subject/Observer done right. This means developers can leverage a single subscribe method, so new data is automatically streamed into particular methods. Developers can focus on describing a subscription in a way that they can be torn down once they are done and cleaned up automatically at the end.

It is exciting to be in the Observables world now.

Matthew Podwysocki,
principal software engineer at Microsoft

This approach makes it easier to implement first-class asynchronous values. This makes it possible to implement the majority of asynchronous code with Observables that can be written with a few simple functions. Podwysocki said this only came off when Google decided it would build Observables into Angular going forward.

There is some discussion about baking Observables into the ECMAScript 2017 JavaScript spec. This would allow developers to leverage these patterns without relying on a particular library. This work on Observables as part of the official JavaScript spec is in its early stages and is still fairly rough. "It is exciting to be in the Observables world now," Podwysocki said.

Podwysocki recommended developers check out the following resources on leveraging Observable design pattern:

Getting started:

• reactivex.io
• Taking Advantage of Observables in Angular 2 Part 1
• Taking Advantage of Observables in Angular 2 Part 2
• Node.js + RxJS on the Server

Libraries:

• ngrx
• Cycle.js
• Yolk.js
• Fluorine
• Redux Saga RxJS

How does Observable design pattern work best with reactive systems? Let us know.

Next Steps:

Reactive systems may be the future

How design patterns impact Java EE7

SOA patterns and design pattern language