Reactive Microservices — 7

This is an 8 part series on reactive microservices. [1 , 2 , 3, 4, 5, 6, 7, 8]

Part 2 , 3 , 4 , 5 & 6 of this services listed reactive microservices patterns. This part continues to list more patterns.

Reactive UI

The theme of writing UI in reactive frameworks is same as writing a reactive microservice i.e. non-blocking, async, event-driven communication. This is applicable in the reactive microfrontends.

In context of UI (Browser, Mobile Native) reactive manifesto can mean:

RESPONSIVE

• The UI should not halt while processing user input or fetching data from server.
• UI Errors should be handled so that UI itself doesn’t crash.
• Parallelization needs non-Blocking
• IO across network should be time-bound (should time-out) to halt the wait for response to ensure responsiveness.

RESILIENT

• UI failures need to be recoverable and should not bring down the application. This API or server failures should be handled gracefully.
• Error should be handled as event.

MESSAGE-DRIVEN

• Typically means responses from a server call (as streams) should be handled as non-blocking events.
• Applications implemented in reactive UI, don’t wait for a response to update a portion of DOM and like CompletableFuture, the script moved ahead with a Promise that whenever and if result arrives, the user UI will reflect the same. Nothing freezes in anticipation of wait.
• One of the UI patterns also is a Message carousel or a message notification which keeps displaying the results of submitted user operations. On similar lines is singular message window that displays result of latest message response.

The UI behavior for browser-based applications is programmatically controlled by JavaScript which provides ability to attach listeners to DOM events, DOM manipulation and AJAX calls over the network. In a sense JavaScript is closer to functional thinking than other programming languages (apart from support object-oriented and imperative programming as well). There is a well-defined observer-pattern via event listeners. The AJAX (Asynchronous JavaScript and XML), as the terms suggests is async, but in raw form doesn’t provide non-blocking, stream processing. Reactive UI JS frameworks provide this support via Promise, Yield, Await, Stream constructs.

In terms of DDD activities that can originate from UI, the expected behavior can be:

Command

• Issue a command and asynchronously wait for acknowledgement back.
• If acknowledgement doesn’t contain errors, display a “Received-Processing” message.
• Ideally provide a push notification (like via web-sockets) for browser to receive the result of command processed event. Or provide a way to query the processing status via “Refresh” type features.
• The commands that trigger long running transactions should communicate via events and provide the user ability to check the state of the transaction, idempotently.

Event

• Domain Events don’t usually originate from the UI but may need to be consumed in the UI.
• Again, if an event is expected back as part of command, it needs to be asynchronous and non-blocking.
• Provide a message/notification section that can allow a user to read all events of interest from the application at one place.

Query

• The queries are heavy used in most web applications for search, reporting or simple data-pull.
• Response to a query updates the UI to show data to the user in any appropriate format.
• The reactive UI should process query response as a bounded stream using object such as Promise.
• The query call should be time-bound and should be explicit about time-out errors.

Reactive JS Libraries:

• RxJS: https://rxjs-dev.firebaseapp.com/guide/overview
• ngrx: https://ngrx.io/
• Angular RX Library: https://angular.io/guide/rx-library
• React Redux: https://react-redux.js.org/
• Bacon.js: https://baconjs.github.io/
• Ember.js: https://emberjs.com/
• Kefir.js: https://kefirjs.github.io/kefir/
• TypeScript: https://www.typescriptlang.org
• JSX: https://reactjs.org/docs/introducing-jsx.html
• Vue: https://vuejs.org/

The Reactive Aspects in the framework provide these features:

• Observer & Iterator Pattern over event stream (Observable, Observer, Subscription, Subject)
• Functional Programming Style (Operators like map, filter, reduce etc.)
• Event Flow Chaining to reduce nested call-backs (http://callbackhell.com/)
• Parallelism via Asynchronous task support
• Non-Blocking via Promise Objects that can be passed around. (to reduce http://callbackhell.com/).
• Objects and Relationships

This is an 8 part series on reactive microservices. [1 , 2 , 3, 4, 5, 6, 7, 8]