The source code for this post can be found on Github.

The completely rewritten AWS SDK for Java 2.0 comes with full reactive programming support all the way down. I wanted a way to test it out without spending any more or being at risk of spending too much money, so I used localstack. This post is largely walking you through what I came up with.

There are use cases for wanting to immediately subscribe to a Flux or a Mono immediately after the subscription has completed. The most obvious use case is if your application needs to continuously poll for values.

The source code for this post is available on GitHub.

One of the nice things about a reactive programming model is there is a significantly lower risk of doomsday when things start getting latent all at once. You don’t have threads upstream blocking and waiting for a response, therefore they won’t all seize up and stop serving requests [or they won’t short circuit if you’re using a resiliency library like hystrix].

The source code for this post can be found on Github.

Mock Server is a really simple and straightforward way to actually let your application make downstream calls and intercept them. That level of abstraction is really nice to have, and gives at least me much more confidence that my code is actually working in a microservices environment.

The source code for this post can be found on Github.

The most straightforward way to write unit tests in spring boot webflux is to leverage project reactor’s StepVerifier. StepVerifier allows you to pull each item in a Flux or the only potential item in a Mono and make assertions about each item as it’s pulled through the chain, or make assertions about certain errors that should be thrown in the process. I’m going to quickly walk you through an example integrating mockito with it and webflux.

The OpenAPI Specification is an “industry standard” way of declaring the API interface. As REST APIs using JSON have dominated the way we move data around in most organizations and on the internet, particularly in service oriented architectures, and as documentation at almost every company has been written once, read a couple of times, then lost to the wind, smart people have figured out that they can put the documentation for their services living with the code–better yet, displayed while the app is running.

The source code for this post can be found on Github.

When you make the switch to a reactive codebase, ThreadLocal becomes effectively off limits to you, because you aren’t guaranteed that the thread that starts the request processing remains the same, even if it’s the same HTTP request. This has caused pain in many places: the original implementation of spring security, for example, relied very heavily on ThreadLocal variables to store state that happened in the start of the request, and then reuse the information stored in those variables later on to make access control decisions. Neflix spoke of their pain migrating to a reactive stack, when they had relied so heavily on ThreadLocal variables in most of their shared libraries.

In my last post on getting started with spring boot webflux and AWS DynamoDB, I mentioned that it wasn’t immediately obvious to find a way to customize the response code in a spring boot RestController, so I opted to use handlers instead.

Reactive Programming is a very different way of thinking about doing work in a microservices environment. Anyone who has worked with a GUI, dating back to even to windows forms, is familiar with the event based model, but what does that mean when there is unpredictable latency involved? How does handing off to a thread to make a remote call differ from this new “reactive web”?

Spring Boot’s WebFlux programming model is pretty neat, but there isn’t a lot by way of explaining how to best leverage it to get the results you need. I wrote this blog post after tinkering with the configuration of Reactor Netty on Spring Boot.