Reactive programming is all the rage at Fluent 2016
Find out why Microsoft's Matthew Podwysocki said he believes good reactive programming means developers embrace the Observable design pattern and create reliable, asynchronous systems.
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.
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.
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.
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.
Podwysocki recommended developers check out the following resources on leveraging Observable design pattern:
- Taking Advantage of Observables in Angular 2 Part 1
- Taking Advantage of Observables in Angular 2 Part 2
- Node.js + RxJS on the Server
- Redux Saga RxJS
How does Observable design pattern work best with reactive systems? Let us know.
Reactive systems may be the future
How design patterns impact Java EE7
SOA patterns and design pattern language