This document discusses Reactive MicroServices using RSocket. It provides an overview of reactive programming and RSocket, which is a binary application protocol that provides reactive streams semantics over TCP, WebSockets, and Aeron. RSocket supports four interaction models - request-response, fire-and-forget, request-stream, and channel. It is transport agnostic and has implementations in many languages. RSocket enables reactive capabilities everywhere by removing roadblocks and supporting interactions beyond just request-response.
Overview of reactive microservices with RSocket, emphasizing reactive programming as an asynchronous data stream paradigm.
RSocket is a binary protocol for reactive streams, supported by various implementations like Java, Kotlin, and Python.
Discusses RSocket's bi-directionality, multiplexing, message-driven protocol, and back pressure for efficient data handling.
RSocket's motivation focuses on removing barriers to reactive programming, supporting diverse interaction models and application protocols.
Looks at the differences between gRPC and RSocket, highlighting RSocket's reactive capabilities and lack of native web components.
Speculations on RSocket's future and mentions other incubation projects like Spring R2DBC and Spring Reactive Gateway.
Introduction to Netifi, a cloud-native platform using RSocket, which enhances operational efficiency with AI features.
Demonstrates implementation specifics for RSocket clients and servers, covering various messaging methods such as Fire-Forget and Request-Response.Collection of links offering more information about RSocket, including tutorials and presentations.
Binary application protocol providingreactive streams semantics using (a)sync message passing over a single connection for use on byte stream transports (as TCP, WebSockets and Aeron)
Bi-Directional ● Both partnerscan be client and server ● No client/server distinction ● No requestor/responder distinction ● Even HTTP/2 makes this distinction
17.
Multiplexed ● HTTP 1.0one connection per request => very inefficient ● HTTP 1.1 pipeline (no random order) => head-of-line blocking ● Multiple “logical streams” within one connection ● Messages are tagged with stream-id ● Random order
18.
Message Driven BinaryProtocol ● Message split into discrete binary frames ● Machine-to-machine efficiency ● Payload can be anything
19.
Reactive Streams BackPressure ● TCP already queues data to some extent ● Reactive Streams (pull-push) backpressure: ○ Materialize data ○ Transfer data ○ Only when receiver is ready
Motivation ● support forinteraction models beyond request/response such as streaming responses and push ● application-level flow control semantics across network boundaries (async pull/push of bounded batch sizes) ● binary, multiplexed use of a single connection ● support resumption of long-lived subscriptions across transport connections ● need of an application protocol in order to use transport protocols such as WebSockets and Aeron
24.
gRPC vs RSocket ●Framework ● HTTP/2 ● Protobuf ● No native web component ● No reactive semantics