chapter eight

8 Reactive in an imperative world

 

This chapter covers:

  • Importance of responsive microservices
  • 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 task can require different amounts of time to complete it, but both be considered responsive. Developing responsive microservices is key in a modern age where users, the customer, 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", an application being able to remain responsive while sustaining high load is critical.

While there are different aspects to being Reactive, this chapter will focus on utilizing Reactive Streams to create an execution pipeline within an application, and between applications. After learning about Reactive Streams, the chapter will introduce the MicroProfile Reactive Messaging specification, covering how it’s used to build responsive microservices. Including how to interact with Apache Kafka, or other messaging systems. The last section of the chapter explains how developers can bridge their imperative and reactive code within a single application, or microservice.

8.1 What are Reactive Streams?

8.1.1 Publisher

8.1.2 Subscriber

8.1.3 Processor

8.1.4 Importance of Back Pressure

8.2 Reactive Messaging in Quarkus

8.2.1 Bridging Imperative to Reactive with Emitters

8.2.2 What about blocking?

8.2.3 Testing "in memory"

8.3 How does it work?

8.3.1 MicroProfile Reactive Messaging specification

8.3.2 Message content and Metadata

8.3.3 Messages in the stream

8.4 Deploying to Kubernetes

8.4.1 Apache Kafka in Minikube

8.4.2 Putting it all together

8.5 Summary