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.

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

The latest AWS SDK for java uses a reactive client to send requests to various AWS services, including DynamoDB. Reactive programming is ultimately more robust at the edges–once you start experiencing latency anywhere in your stack, if your tech is not reactive, you’re going to have a significantly worse time than if it were.

In this article, I’m going to show you how to bootstrap a local kubernetes cluster with a custom image, debug it, deploy a new image, then rollback to the old image.

Sample code associated with this post can be found on Github.

Rest Assured is a library that makes it easy to write api based automated tests in java. Recently I needed to find a way to record the latency of each request as well as some metadata about it [request path, method, things of that nature]. I found a nice way to do this with rest assured filters, and I’m going to share that with you in this article.

There is some [hacky] code for this post on Github.

The number of hystrix configuration options, as of this writing, is about 34. In reality, you don’t need to worry about most of them, as the defaults are perfectly reasonable. This article discusses those parameters that, in my experience, you typically need to pay attention to and tune, and I have provided some examples using spring boot’s support for hystrix via the javanica library.