Robert Hedgpeth - R2DBC Revealed: Reactive Relational Database Connectivity for Java and JVM Programmers

Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the books product page, located at www.apress.com/9781484269886 . For more detailed information, please visit http://www.apress.com/source-code .

One of the few stable things in information technology is constant change.

Software, once written as machine code, then by using compilers, went (and still goes) through various paradigm changes: procedural, data driven, object oriented, functional. There have been many more programming models, and others will follow. Patterns come and go as we speak. All this is driven by purpose, capabilities of our runtime environments, constraints, and business requirements.

In a similar way, the way how we consume software services has changed many times. Back in the 1990s, software was primarily installed locally and sometimes backed by a server. Think of your good old desktop computer. The 2000s are characterized by online services. More and more services became available through the Internet, all hosted in their own data centers. Businesses began investigating web applications to avoid installing software on each machine. Data centers grew.

The 2010s finally set the stage for software-backed services to run in the cloud. Many online services were founded these years. Its the golden digital age. Businesses driven by software can simply scale by adding another batch of machines to their data center to serve more customers, or in their cloud.

Scalability is only constrained by the remaining capacity in a data center, the investment in servers, and the operational cost for computer systems. Scaling a business comes with many challenges. One of them is efficiency. Efficiency becomes an important metric to measure how well a system is utilized compared to its cost.

But what impacts the efficiency and scalability of an application?

To answer this question, we have to get to the bottom of an application and its programming language. Are you ready to dig through the physiology of applications? Ready? Go!

All applications have in common that they require computation power and memory to fulfill their work. How many concurrent requests/users/processes/ a single machine can handle depends primarily on CPU and memory demand. It also depends on how CPU and memory are used with a strong tie to the duration in which resources get occupied.

Typical enterprise applications on the JVM follow an imperative programming style that guarantees synchronization and order of execution for each individual statement.

Imperative programming comes with certain effects that arent immediately visible. One of these effects is how I/O gets handled and how it affects threads. Typically, applications require an integration with a database, message broker, or another remote service to perform their work. When communicating with remote integrations, the network becomes an integral part of the work that has to be done. It becomes a driver for latency. Network performance and remote peer performance become a factor that affects scalability as I/O causes to block the underlying thread. Threads require memory and CPU. You cant have an infinite number. That being said, threads impose a primary constraint for application scalability.

With sufficiently high I/O load, machines can be kept busy with waiting for I/O they basically wait all the time with CPU and memory being maxed out. As you might already tell, such an arrangement isnt efficient.

Now that we have identified constraints for scalability and efficiency, we should take a look at what we can do about this aspect.

There are various approaches to overcome the limitations of the imperative programming model. The most significant and most efficient one is just not using blocking I/O. Using non-blocking I/O is all but trivial.

In the JVM space, we can use various abstractions that help with developing highly efficient applications. So far, the only consistent programming model that helps with non-blocking I/O is reactive programming. Reactive programming is heavily stream and event oriented. It is characterized by pipeline definitions, operators, and a functional programming style. Reactive programming leads to a well-structured code that isnt cluttered with endless callbacks.

Data sources, internal and inter-process sources, follow the same style. The reactive runtime and its integrations encapsulate threading and the non-blocking I/O business. Reactive drivers expose a convenient API that can be directly used without worrying about how to use non-blocking I/O.

Reactive programming on the JVM is still a young endeavor. In the past years, an inter-op standard emerged to connect reactive libraries so that they can interact with each other. This standard is Reactive Streams.

The very first abstractions that followed Reactive Streams were composition libraries, web frameworks, messaging libraries, and the MongoDB client.