Reactive programming is a hot topic and something that I have been following with interest. Essentially, it involves a programming paradigm that reacts to stimulus which can be modelled as an event or data stream. It isn’t really a new paradigm, as spreadsheets have been using this for a long time. When you create a chart based on the value of certain cells, as you change the input in the cells, the chart ‘reacts’ to the input stream and modifies itself. The reactive programming model permeates right through all application layers from backend services (data changes), front-end applications ( user stimulus such as keyboard events) and interactions with external services (twitter streams) . It also implies a shift from imperative style of programming to asynchronous, functional-style code (no callback hell). This results in high responsive user experiences and communication patterns that enable a decoupled micro-services architecture.
What is it good for?
There are numerous applications where reactive principles can bring immense benefits and simplify the programming and architectural models. Some of the more obvious ones are:- User experience related features: search, sign up process (checking if the user already exists)
- Social or networking style apps: collaborative document authoring, group calendars, messaging/chat apps
- Multiplayer games
- Financial event based systems
- Robotics
- Sensor networks and IoT
Key Constructs: Streams and Observables
Modern reactive programming framework such as RxJS (and other language flavours) offer efficient semantics and constructs for writing non-blocking services and applications. The core concepts of reactive programming models are streams, operators and subscriptions (bindings).
Streams:
As mentioned before, streams are sequences of events ordered in time. Stream events can be almost anything - a mouse clicked, a page view, an error event, an Instagram post, a person of interest entering a watch zone.
Transformation:
Streams can be transformed, combined to create new immutable streams that can then be subscribed or listened to by consumers. This is the old observer pattern from the GOG book but there are some key distinctions which I will cover later.
Ref: http://rxmarbles.com
Also, event streams can be generated from continuos sources as as illustrated below:
Subscription/Binding:
Streams are ‘observed’ or ‘listened’ to by means of a special implementation of the Observer patter called as an Observable. The Observable is similar to the Iterable but unlike the Iterable where the consumer pulls the data from the Iterable, the observable pushes data to the consumer when data is available, signals to the consumer when no more data is available and signals when an error has occurred.
The Reactive Toolset
While there is a plethora of choices available to programmers for building reactive applications, these are my leanings:
- RxJS with bindings for several languages
- Akka Streams,
- Angular2, AngularFire, Firebase
In the next part of this article, I will cover prototyping a real time auction application using some of the reactive programming concepts and the toolset listed above.
No comments:
Post a Comment