Hands-On Reactive Programming in Spring 5

Build cloud-ready, reactive systems with Spring 5 and Project Reactor

Oleh Dokuka, Igor Lozynskyi

• Editorial: Packt Publishing
• Año: 2018
• ISBN:
  9781787287297
• Edición: 1
• Categoría: Computer Science
• Categoría: Programming in Java

Explore the reactive system and create efficient microservices with Spring Boot 2.1 and Spring Cloud

Key Features

• Understand the kind of system modern businesses require with Spring
• Gain deeper insights into reactive programming with Reactor and Spring Cloud
• Get in-depth knowledge on asynchronous and nonblocking communication with Spring 5 WebFlux

Book Description

These days, businesses need a new type of system that can remain responsive at all times. This is achievable with reactive programming; however, the development of these kinds of systems is a complex task, requiring a deep understanding of the domain. In order to develop highly responsive systems, the developers of the Spring Framework came up with Project Reactor.

Hands-On Reactive Programming in Spring 5 begins with the fundamentals of Spring Reactive programming. You'll explore the endless possibilities of building efficient reactive systems with the Spring 5 Framework along with other tools such as WebFlux and Spring Boot. Further on, you'll study reactive programming techniques and apply them to databases and cross-server communication. You will advance your skills in scaling up Spring Cloud Streams and run independent, high-performant reactive microservices.

By the end of the book, you will be able to put your skills to use and get on board with the reactive revolution in Spring 5.1!

What you will learn

• Discover the difference between a reactive system and reactive programming
• Explore the benefits of a reactive system and understand its applications
• Get to grips with using reactive programming in Spring 5
• Gain an understanding of Project Reactor
• Build a reactive system using Spring 5 and Project Reactor
• Create a highly efficient reactive microservice with Spring Cloud
• Test, monitor, and release reactive applications

Who this book is for

This book is for Java developers who use Spring to develop their applications and want to build robust and reactive applications that can scale in the cloud. Basic knowledge of distributed systems and asynchronous programming will help you understand the concepts covered in this book.

Reactive Database Access

The previous chapter introduced a new addition to the Spring Framework family—Spring WebFlux. This addition brings reactive programming to the application front and enables non-blocking processing of HTTP requests of all kinds.

In this chapter, we will learn how to access data in a reactive manner using Spring Data modules. This ability is vital for the creation of an entirely reactive and responsive application that leverages all available computing resources most efficiently, delivering the maximum business value and also requiring a minimal operational cost at the same time.

Even if our database of choice does not provide a reactive or asynchronous driver, it is still possible to build a reactive application around it using a dedicated thread pool—this chapter covers how to do this. However, blocking I/O is always discouraged in reactive applications.

In this chapter, we cover the following topics:

• Patterns of data storage and data processing in the modern world
• Pros and cons of synchronous data access
• How Spring Data allows reactive data access and how to use this in reactive applications
• What reactive connectors are available at the moment
• How to adapt blocking I/O to the reactive programming model

Data handling patterns in the modern world

Even though monolithic software systems still exist, operating on and supporting a lot of our everyday activities, most new systems are designed for—or at least at some point are transitioned to—microservices. Microservices is now probably the most dominant architectural style for modern applications, especially cloud-native applications. In most cases, this approach allows a rapid development cycle for a software product. At the same time, it also provides an opportunity for more cost-effective underlying infrastructure (servers, networking, backups, and so on), especially when relying on cloud providers such as AWS, Google Cloud Platform, or Pivotal Cloud Foundry.

For more information about cloud-native applications, see the Cloud Native Computing Foundation (CNCF) Charter at https://cncf.io/about/charter. More pros and cons of cloud-native applications in the context of reactive programming are covered in Chapter 10, And, Finally, Release It!

We will now take a look at an overview of the basics of data storing in the context of microservices, possible strategies, implementation approaches, and some recommendations related to data persistence.

Domain-driven design

Domain-driven design (DDD) by Eric Evans (Addison-Wesley, 2004) should occupy an honored place on every software engineer's bookshelf. This is because it defines and formalizes an important theoretical basis for a successful microservices architecture. DDD establishes a common vocabulary (namely, context, domain, model, and ubiquitous language) and formulates a set of principles for maintaining model integrity. One of the most important consequences of DDD is that individual bounded contexts defined in terms of DDD are usually mapped into separate microservices, demonstrated as follows:

Diagram 7.1 Bounded contexts (good candidates for microservices) as depicted by Vaughn Vernon, the author of Implementing Domain-Driven Design and Domain-Driven Design Distilled

Since DDD is very focused on the business core domain, especially on artifacts to express, create, and retrieve domain models, the following objects will often be referenced during this chapter—entity, value objects, aggregate, repository.

To learn more about DDD concepts, please read the following article: http://dddcommunity.org/resources/ddd_terms.

During application implementation with DDD in mind, the preceding objects should be mapped to the application persistence layer if such a layer is present in the service. Such a domain model formulates the basis for logical and physical data models.

Data stores in the era of microservices

Probably the leading persistence-related change introduced by the microservices architecture is strong encouragement to not share data stores between services. This means that each logical service owns and manages its database (if it requires a database at all) and ideally no other service can access the data in a way that is different from a service API call.

It is out of this book's scope to explain all the reasons for such separation, but the most important ones are as follows:

• The ability to evolve different services separately, without tight coupling on a database schema
• The potential for more precise resource management
• The chance of horizontal scalability
• The possibility to use the best fit persistence implementation

Consider the following diagram:

Diagram 7.2 Separate database per service...