Blog Posts by Dave Syer

Client Side Development with Spring Boot Applications

December 17, 2021

This article explores the different options that Spring Boot developers have for using Javascript and CSS on the client (browser) side of their application. Part of the plan is to explore some Javascript libraries that play well in the traditional server-side-rendered world of Spring web applications. Those libraries tend to have a light touch for the application developer, in the sense that they allow you to completely avoid Javascript, but still have nice a progressive "modern" UI. We also look at some more "pure" Javascript tools and frameworks. It’s kind of a spectrum, so as a TL;DR here is a list of the sample apps, in rough order of low to high Javascript content:

htmx: HTMX is a library that allows you to access modern browser features directly from HTML, rather than using javascript. It is very easy to use and well suited to server-side rendering because it works by replacing sections of the DOM directly from remote responses. It seems to be well used and appreciated by the Python community.
turbo: Hotwired (Turbo and Stimulus). Turbo is a bit like HTMX. It is widely used and supported well in Ruby on Rails. Stimulus is a lightweight library that can be used to implement tiny bits of logic that prefer to live on the client.
vue: Vue is also very lightweight and describes itself as "progressive" and "incrementally adoptable". It is versatile in the sense that you can use a very small amount of Javascript to do something nice, or you can push on through and use it as a full-blown framework.
react-webjars: uses the React framework, but without a Javascript build or bundler. React is nice in that way because, like Vue, it allows you to just use it in a few small areas, without it taking over the whole source tree.
nodejs: like the turbo sample but using Node.js to build and bundle the scripts, instead of Webjars. If you get serious about React, you will probably end up doing this, or something like it. The aim here is to use Maven to drive the build, at least optionally, so that the normal Spring Boot application development process works. Gradle would work the same.
react: is the react-webjars sample, but with the Javascript build steps from the nodejs sample.

There is another sample using Spring Boot and HTMX here. If you want to know more about React and Spring there is a tutorial on the Spring website. There is also content on Angular via another tutorial on the Spring website and the related getting started content here. If you are interested in Angular and Spring Boot Matt Raible has a Minibook. The spring.io website (source code) is also a Node.js build and uses a completely different toolchain and set of libraries. Another source of alternative approaches is JHipster which also has support for a few of the libraries used here. Finally the Petclinic, while it has no Javascript, does have some client side code in the stylesheets and a build process driven from Maven.

"Wiremock" for RSocket

Engineering

June 2, 2021

If you have an application that connects to an RSocket server at runtime, how do you test it? We need a way for a test to start a server and tell us where it is listening, and then we need to be able to register request and response examples (a.k.a. "contracts"). That’s what this project provides - it’s like Wiremock but for RSocket.

Getting Started

The easiest way to use the project is as a JUnit (Jupiter) extension, e.g:

@SpringBootTest
@ExtendWith(RSocketServerExtension.class)
class SocketsApplicationTests {
	...
}

With this extension installed the Spring Boot tests will run with an RSocket server listening on a port given by test.rsocket.server.port, so the test can connect directly to it, or (more likely) the code that it is testing will connect to it. You might need to tell it where to connect via the @SpringBootTest annotation, e.g. if the application is looking for a property at runtime called rsocket.port:

@SpringBootTest("rsocket.port=${test.rsocket.server.port}")
@ExtendWith(RSocketServerExtension.class)
class SocketsApplicationTests {
	...
}

Spring Cloud Function Native Images

Engineering

May 4, 2020

Here’s the latest graph of memory versus billing for Spring Cloud Function on AWS Lambda. It shows the billing metric GBsec as a function of memory allocation in Lambda for two custom runtimes, one in plain Java and one using a GraalVM native image, as described recently in this blog by Andy Clement:

aws-billing-3.x

In both cases the functionality is identical (a simple POJO-POJO function), and they both show only the results for cold start. Warm starts, where the function was already active when the request came in, were much faster and cheaper (except for the smallest memory setting they all cost the same because there is a minimum charge for all functions in AWS). You can see that the native images start up very fast and that they are more than two times cheaper to run than the regular JVM. The fastest startup was in the 1000MB container - it only took 19ms to start the app, but it took AWS 700ms to prepare the container, so it was billed at 800ms. In fact, all of the cold starts were billed at 800ms for the native image. For the regular JVM the fastest startup was also in the 1000MB container at 300ms, but it was billed at 2200ms.

Manual Bean Definitions in Spring Boot

Engineering

January 21, 2019

Suppose you want to use Spring Boot, but you don’t want to @EnableAutoConfiguration. What should you do exactly? In an earlier article I showed that Spring is intrinsically fast and lightweight, but one of the short pieces of advice improve startup time was to consider manually importing the Spring Boot autoconfigurations, instead of sucking them all in automatically. It won’t be the right thing to do for all applications, but it might help, and it certainly won’t hurt to understand what the options are. In this piece we explore various ways of doing manual configuration and assess their impact.

How Fast is Spring?

Engineering

December 12, 2018

Performance has always been one of the top priorities of the Spring Engineering team, and we are continually monitoring and responding to changes and to feedback. Some fairly intense and precise work has been done recently (in the last 2-3 years) and this article is here to help you to find the results of that work and to learn how to measure and improve performance in your own applications. The headline is that Spring Boot 2.1 and Spring 5.1 have some quite nice optimizations for startup time and heap usage. Here’s a graph made by measuring startup time for heap constrained apps:

Spring Boot in a Container

Engineering

November 8, 2018

Many people are using containers to wrap their Spring Boot applications, and building containers is not a simple thing to do. This is an article for developers of Spring Boot applications, and containers are not always a good abstraction for developers - they force you to learn about and think about very low level concerns - but you will on occasion be called on to create or use a container, so it pays to understand the building blocks. Here we aim to show you some of the choices you can make if you are faced with the prospect of needing to create your own container.

Functional Bean Registrations in Spring Cloud Function

Engineering

October 22, 2018

Spring Cloud Function has a couple of new features in 2.0 (still in milestone phase), and possibly the most dramatic is the ability to go "fully functional". This is made possible by changes in Spring Boot 2.1 together with Spring Framework 5.1, and it means a different way of thinking about bean definitions in Spring applications, but also significant improvements in startup performance.

AWS Cost Savings

It’s always good to start with a picture, especially if it tells a story. Here’s a graph that shows the improvement in Spring Cloud Function 2.0 over 1.0, comparing the cost of cold starts in AWS:

The x-axis is memory in MB, and the y-axis is cost of a cold start in GBsec. The most dramatic effect is for low memory containers, where the cost is almost 4 times lower with 2.0. The "Custom" function is even faster (10x over Spring Cloud Function 1.0) - it’s a custom AWS runtime using Spring Cloud Function with functional beans. The origin of the improvement is in dramatically shorter startup times, which in turn come from using the functional form of bean definitions in the application. Josh made a video about functional bean registration a while ago if you need an introduction (it’s on YouTube). Now let’s have a closer look at how it works in Spring Cloud Function.

Spring Cloud Function 2.0 and Azure Functions

Engineering

September 25, 2018

Spring Cloud Function has had support for Microsoft Azure Functions since version 1.0, but in the latest 2.0 releases (still in milestone phase) we decided to change the programming model a bit. This article describes what the changes mean for users, and provides a bit of background behind the shift. We in the Spring team had a lot of fun working on this and collaborating with the folks at Microsoft to get the best blend of the two technologies for our users.

Azure Functions for Java

Microsoft has had Java support in Azure Functions for a while, and it enables developers to easily write and deploy Java code that connects in a serverless way to a wide range of platform services (events, databases, storage, HTTP gateways, etc.) in Azure. It comes with an annotation-based programming model that puts the function implementations in Java methods. So you write a method and annotation it with @FunctionName, and it becomes an Azure Function. There is a rich set of tools based on a Maven plugin (currently) that drives the Azure command line and can be used to build a function, run and debug it locally and deploy it to the cloud. There is a Quickstart Guide on the Azure website which will help you get all the pre-requisites installed and working, and there is more detailed documentation about how Azure Functions works in the Developer’s Guide.

The Joy of Mustache: Server Side Templates for the JVM

Engineering

November 21, 2016

I don’t do much server-side templating, but when I do… well frankly, I tend to forget things. Every template language has its strengths and weaknesses, and they all have syntax to remember, and more frequently to forget. Recently I completed some work on the old Spring Petclinic, converting it to use Thymeleaf in the view layer, and re-organizing the code to be a bit more "modern". I enjoyed working with Thymeleaf 3, and found it a pleasant experience, but had to spend a lot of time scanning documentation and samples. Then I had another little project that needed some templates, and I remembered my fondness for Mustache, which we added to Spring Boot back in version 1.2, and which plays an important role in the excellent Spring REST Docs tool. I added spring-boot-starter-mustache to my new project, and was up and running within seconds.

Notes on Reactive Programming Part III: A Simple HTTP Server Application

Engineering

July 20, 2016

In this article we continue the series on Reactive Programming, and the focus is less on learning the basic APIs and more on more concrete use cases and writing code that actually does something useful. We will see how Reactive is a useful abstraction for concurrent programming, but also that it has some very low level features that we should learn to treat with respect and caution. If we start to use these features to their full potential we can take control of layers in our application that previously were invisible, hidden by containers, platforms and frameworks.