In the mission of the cloud-native computing foundation, It states “the techniques enable loosely coupled systems that are resilient, manageable, and observable.” Those three characterizes are the core of the cloud-native computing foundation. Other technologies play a support role.

1. Reactive Programming

1.1 Imperative Programming vs. Reactive Programming

With an imperative approach, a developer writes code that describes in exacting detail the steps that the computer must take to accomplish the goal. Those steps are executed in the order as the developer lays out without considering other systems the code interacts with.

With a reactive approach, a developer can build a non-blocking, asynchronous code that can handle back-pressure (flow control). As a result, the code will observe and react to any actions outside of the system without being restricted by the code programming instruction. It will work well under the pressure.

1.2 Reactive Stream

The Reactive stream is about I/O, asynchronous stream processing with non-blocking backpressure. Asynchronous is about situation and non-blocking is about handling. It has an advantage in a large data processing system.

The concept of backpressure is that a client is a king to ensure the other party can handle its task properly with a given amount of data. For example, in an airport check-in line, the counter clerk will ask whoever on the line comes to the counter once the clerk is available to provide a service. It could be one person or a group of several people coming forward to the check-in counter. That is to say, that node sends a signal on how much data it can handle and the other node sends over data within the data amount the part indicates at the time. In such fashion, a node will handle amount of traffic date it can handle from other nodes.

In terms of asynchronous, any programming languages created in the past decade have the feature. It comes with different terms such as callback-based, Rx/Reactor, co-routines, asynchronous/await, etc. in the form of either build-in and library.

2. RSocket

Although various programming languages have a reactive feature, none of those languages have a mechanism of communication in a reactive fashion. For example, two parties/nodes can be reactive on their own, but there isn’t a correlation between them in a reactive fashion. That could lead to an application system break under high pressure. One party/node could engage a communication while the other party/node is busy with a heavy data load. That is the motivation of the circuit break design pattern. The design pattern can be used to check the availability of an external service and detects failures and prevents the application from trying to perform the action that is doomed to fail.

To address this issue, a new application protocol, RSocket, a new application protocol for multiplexed, duplex communication, is formed. Like many cloud-related open source technologies, it was initially developed by NetFlix. Its initial release was in October 2015.

RSocket is a binary protocol for use on byte stream transports such as TCP, WebSockets, and Aeron. The “R” stands for reactive. A network socket is an internal endpoint for sending or receiving data within a node a computer network. Concretely, it is a representation of this endpoint in networking software and is a form of system resource. RSocket is on the same level of HTTP in the communication protocol layer.

RSocket honors reactive syntax for modern cloud application and it has the following features:

• Provides a standard approach to connecting and communicating
• Solves a problem in a consistent way across your applications

In the language scope, RSocket doesn’t reinvent the wheel. In different languages, RSocket achieves its goal with various approaches with existing features and/or libraries. For example, it uses the Reactor in Java. It uses the Event-Loop of Node.js in Javascript. And it uses Goroutines in Go.

2.1 RSocket Interaction Models

As mentioned before, RSocket is on the same level of HTTP in the communication protocol. Http is designed for communication between humans and a computer. After a human submits a request to a computer through a web browser, the computer will send some human-readable data back based on the request. Http is not designed for communication between computers.

RSocket has four communication interaction models. Those four models cover all communication requirements between computers. It enables the following symmetric interaction models via async message passing over a single connection:

**request-response **— send one message and receive one back

In this interaction model, RSocket behavior likes HTTP. A request is sent and a response will be returned based on the request. In this model, RSocket won’t show any advantages in a low data flow situation.

fire-and-forget — send a one-way message

It is used in a situation that an application doesn’t need to wait for an action result of an external system. For example, acknowledgment isn’t needed in the situation for writing a message into an external log file system.

**request-stream **— send one message and receive a stream of messages back

One example of the usage scenario is requiring a video file, one party sending a request, and the other party sending back a stream of video data based on the request.

**channel **— send streams of messages in both directions

One example of using the channel is online chat. A connect is set up on both ends and data constantly flow forward and backward between those two ends.

#tutorial #microservices #reactive #reactive architecture #rsocket #reactive development