8 Reactive in an imperative world

 

This chapter covers

  • Importance of responsive microservices
  • The MicroProfile Reactive Messaging specification
  • Sending and receiving messages with Apache Kafka

A Microservice being responsive refers to its ability to complete the task required of it within a given time. The complexity of the task will impact the time a microservice takes to complete its work. Different microservices performing their tasks can require different amounts of time to complete them, yet both be considered responsive. Developing responsive microservices is key in a modern age where users—the customers—are expecting near instantaneous loading of web pages and answers to their queries. Microservices that are not responsive enough will fail when subjected to intensive high load. In an age of “going viral,” it is critical that an application remain responsive while sustaining high load.

Although being reactive represents different aspects, in this chapter we focus on using Reactive Streams to create an execution pipeline within an application and between applications. After covering Reactive Streams, we introduce the MicroProfile Reactive Messaging specification and how it’s used to build responsive microservices, including how to interact with Apache Kafka or other messaging systems. In the last section of the chapter, we explain how developers can bridge their imperative and reactive code within a single application or microservice.

8.1 Reactive example

8.2 What is Reactive Streams?

8.2.1 Publisher, Subscriber, and Processor

8.2.2 The importance of back pressure

8.3 Reactive Messaging in Quarkus

8.3.1 Bridging from imperative to reactive with emitters

8.3.2 What about blocking?

8.3.3 Testing “in memory”

8.4 How does it work?

8.4.1 MicroProfile Reactive Messaging specification

8.4.2 Message content and metadata

8.4.3 Messages in the stream

8.5 Deploying to Kubernetes

8.5.1 Apache Kafka in Minikube

8.5.2 Putting it all together

Summary