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

Lettuce is a redis client with reactive support. There is a super handy embedded redis for java project out there, and this kind of integration testing inside your service is worth its weight in gold, in my humble opinion. This post will detail how to merge both of these worlds together, and set up redis integration tests when you’re using a lettuce client.

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

When someone talks about a caffeine cache, they are talking about Ben Manes caching library, which is a high performance, in memory cache written for java. If you’re using reactive streams, you can’t reliably use a LoadingCache because it’s blocking by default. Thankfully, tapping into a couple of basic features of reactive streams and caffeine can get us there.

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.

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.

You can see the source code for this post on Github.

Following up on the last post [ How to Expose Meaningful Prometheus Metrics In a Spring Boot 2.x Application], if we have metrics exposed but they don’t go anywhere, are there metrics exposed at all?

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

In my last post, I provided an example for how to set up an Nginx Reverse Proxy for a Spring MVC application. One such reason to set up a reverse proxy is to utilize caching of resources. If you have dynamically generated content that doesn’t change very often, then adding caching at the site entry point can dramatically improve site responsiveness and reduce load on critical resources.

Nginx is a popular webserver, excellent at serving up static content, and commonly used as a load balancer or reverse proxy. This post will set up a basic Spring Boot MVC web application, and use Nginx as a reverse proxy. The source code can be found on GitHub.

The sample code associated with what follows can be found on GitHub.

One of the biggest paradigm shifts in software engineering, since the invention of the computer and software that would run on it, was the idea of a MVR (minimum viable release) or MVP (minimum viable product). With the lack of internet access becoming the exception in developed countries, it becomes more and more powerful to put your product out there on display, and to design a way to continuously make improvements to it. In the most aggressive of circumstances, you want to be able to push something up to a source control server, then let an automated process perform the various steps required to actually deploy it in the real world. In the best case, you can achieve all of this with zero downtime–basically, the users of your service are never inconvenienced by your decision to make a change. Setting up one very simple example of that is the subject of this post.

You can view the sample code for this repository on GitHub.

In our last post on Using Maven to Setup and Teardown Integration Tests, we saw how to run Java code before and after our integration tests to setup and teardown any data that our tests depended on. What if we are using Spring, and we want to use our ApplicationContext, and its dependency injection/property injection features? After all, we would be testing the configuration for our specific application more than anything else, so we should be certain to use it in our setup and teardown code.

The sample code for this post can be found on GitHub.

Unit testing with Maven is built in, and is the preferred way of validating code is performing correctly. However, sometimes you need integration testing, and most non-trivial applications built in the 21st century are reliant on network connections and databases–that is, things which are inherently third party to your application. If you don’t adequately take that to account in your CI/CD pipeline, you might end up discovering that something very bad has happened after damage has already been done.