Streaming Live Updates From a Reactive Spring Data Repository

Here's an example implementation of streaming updates from a database to other components

This post details a naive implementation of streaming updates from a database to any other components that are interested in that data. More precisely, we look at how to alter a Spring Data R2DBC repository to emit events to relevant subscribers.

You may also like: Reactive Streams With Spring Data and MongoDB

A little bit of background knowledge of R2DBC and Spring will be helpful for this post. My previous writings: Asynchronous RDBMS access with Spring Data R2DBC and Spring Data R2DBC for Microsoft SQL Server — these should help in that regard.

Callback Hell and Reactive Patterns

One of the ways that I have better understood the usefulness of a Reactive Streams-based approach is how it simplifies a non-blocking IO call.

This post will be a quick walkthrough of the kind of code involved in making a synchronous remote call. Then, we will demonstrate how layering in non-blocking IO, though highly efficient in the use of resources (especially threads), introduces complications referred to as a callback hell and how a Reactive Streams-based approach simplifies the programming model.

Dubbo 3.0 Preview: Support for Reactive Programming

Background

Dubbo is graduating from the Apache foundation! And we are planning some major release milestones. Release 3.0 is on the way. Since there will be many new features in 3.0, we want to make sure they are up to the expectation of the community. We are now offering the 3.0.0-SNAPSHOT version. It has many preview features of the 3.0 release. In this article, I’ll introduce one of the major enhancements: the support for reactive programming.

RSocket

Reactive programming enables developers to write more efficient applications, especially in a distributed architecture. The community has been asking for this feature for a long time and now we are delivering!

Scale Your API Programs With Mule 4

Mule developers build integration solutions that must cater to high volumes of real-time and batch data. In some cases, the size of payloads can be larger than memory. In others, API solutions may have to handle high rates of API calls per second.

Horizontal scalability, whereby Mule instances are deployed across multiple virtual and physical machines, is costly. Thus, a single Mule instance must utilize to the maximum underlying processing and storage resources as it handles traffic. Its ability to handle more traffic with more underlying resources is what we refer to as vertical scalability.