This year the conference was 100% virtual just like last year, and the vibe of the conference was definitely focused on not breaking the developer flow! During the first day keynote, Developer Advocate Josh Long and VMWare CEO (among others) made that really clear!

I could attend several sessions during those 2 days, here are my notes (videos are available when you click on the links to the sessions)

Spring GraphQL, by Andreas Marek, Atlassian and Rossen Stoyanchev

GraphQL was created by Facebook in 2021 for their iOS app; but since then it has been standardized as a specification and even if it’s still mostly used by native clients and Single Page Apps, it can be useful in other scenarios, such as with a bunch of microservices.

GraphiQL is a straightforward GUI app to test out a GraphQL server.

The2 pillars of GraphQL are the schema and the query.

Since the schema and the query models are following an open specification, they have been implemented in many programming languages; including Java

GraphQL Java

You should think about the schema (so that it’ll be useful for the clients) and the DataFetchers: every field has a DataFetcher (it is an interface to implement); the PropertyDataFetcher is a special DataFetcher that reads from POJOs fields (no need for any customization)

Spring GraphQL: the missing gap

Spring and GraphQL Java teams came together and filled this gap!

It includes transport (HTTP, WebSocket), GrapQL Java Engine (context, security, exception resolution) DataFetchers (using the @Controller annotation) and testing thanks to GraphQlTester!

The easiest way to use Spring GraphQl is of course via the starter

Netflix also has their GraphQl support, namely DGS (also built on Spring); using a different starter, you can use DGS with Spring GraphQl java; it’s just an initial integration, more to come.

Spring GrahQl will be GA next year with the release of Spring Boot 2.7

A Tour of the Modern Java Platform by Bruce Eckel and James Ward

Link to the Github repo

The next LTS version of Java is coming this month, Java 17, so this is the occasion to have a look at the recent features!

• Records: immutability makes it easier to reason about; nice toString included !
• var to declare variables (from Java 10 though, not exactly new now!)
• Text blocks; including variable interpolation
• Set.of (from Java 9 though)
• NullPointerException with insightful explanations
• sealed interfaces: list using the permits keyword what are all the implementations available for a given interface: the compiler will be able in switch expressions for example to infer all the different options on a type.
• instanceof with pattern match:

• Tooling: jshell, modules, and jpackage to package an app with the JDK.

James and Bruce then run an app on Google Cloud Run and run some tests using TestContainers

Those tests were actually written in Kotlin, so they continued with explanations of Kotlin features such as co routines, since they were connecting using R2DBC (reactive JDBC) to a PostgreSQL database.

Finally, James containerized the app using (Paketo) buildpacks; and specifying BP_NATIVE_IMAGE=1 , using GraalVM native builds!

James has a nice writeup about this talk on his blog too.

Modern Application Configuration in Kubernetes, by Craig Walls

Github repo for the demo (only configuration, Craig should publish the rest of the code sometimes)

If you use a vanilla Spring Boot application, configuration specified in application.properties / application.yaml are shipped to the deployment target; that’s not ideal when dealing with several target environments (dev, qatest, preprod, etc.)

On the other hand, Environment variables are boud to a given environment but are tricky to audit: who changed them and when?

You could also configure your application providing Command line arguments and JVM system properties… not really easy to use either.

The solution ? Spring Cloud Config Server which can use Vault, Git or S3 as a backend; and the corresponding library in Java exist! The main draw back of this solution was that it was not really integrated with Kubernetes and other programming languages / frameworks.

Then kubernetes and configmaps and secrets came along: they can be mounted as file system or environment variables and work for every programming language; but are not well integrated with a Spring Boot app.

So which to choose? Spring Configuration server or Kubernetes configmaps / secret?

Application Configuration Service for Tanzu: uniting both methods!

Using Tanzu Custom Resources installed in your cluster (any Kubernetes cluster, not just Tanzu) you define your configuration backend (a Git repository that contains a bunch of properties for example) using a ConfigurationSource that will turn thos properties into ConfigMaps! then thanks to a ConfigurationSlice, you can target a specific application for a given configuration

Craig finished the talk mentioning the initial Azure support for Application Configuration Service and during Q&A mentioned that Vault support was not there yet since they focused on Git for their first iteration; so you’d need something else for now for your secrets..

Spring Native by Sébastien Deleuze

Back in March 2021 Spring Boot Native beta was announced and was very well received.

What is Spring native ? the integration of Spring with GraalVM to create a native binary.

Native apps are smaller, consume less memory and faster to boot. But they’re no silver bullets since they don’t benefit from the JVM (management and monitoring, GCs optimizations, etc.)

The Spring Native team had to work on different challenges: long build times, no class lazy loading, JVM libraries less tested on native, Spring API backward compatibility, runtime reflections can be used only with additional configuration (not ideal).

You can get started using start.spring.io and also get support from your IDE (IntelliJ IDEA was shown), and you also get the same buildpacks support that comes with regular Spring applications – even better: no more need to have GraalVM installed on your machine, since they rely on Docker images for that.

A collaboration with the GraalVM team gave birth to native-build-tools : a set of tools for native apps (build them natively locally and run them)

Java (preferably 11) and Kotlin 1.5 are supported, as well as a bunch of Spring libraries.

For your own code or libraries that were not covered, you can use annotations to specify reflections, serializations, initialization hints.

Recently, native testing was added, using Maven or Gradle and JUnit 5.

Mockito and other frameworks heavily relying on reflections are not supported yet

Compression support in buildpacks was added: allows size of the executable to be shrunk by 4! Also on the buildpacks side, Spring collaborated with Bellsoft Liberica to have a specific GraalVM based build image.

The Spring AOT plugin is now core to the build of the native image, generating native configuration and AOT bytecode to be consumed by the native image compiler.

Data points:

• The main native drawback is still the build time, up to 3 minutes for fully fledged app like the Spring Pet Clinic;
• container size image is shrunk by 2 though, even less using UPX compression
• Memory consumption, still for the Spring Petclinic app, is divided by 4
• Startup time: divided by 20!

Sébastien also mentioned GraalVM 21.3 release (coming October 2021) with java 17 support and Java 8 removal, and auto inlining of simple reflection calls

Spring Native 0.11.0 is to be released on November 19th (matching Spring Boot 2.6.0 release) with GraalVM 21.3 support.

Spring Boot 3 (Q4 2022) will provide seamless integration with Spring native.

Spring Boot on Amazon Web Services with Spring Cloud AWS by Maciej Walkowiak and Matej Nedic

They used Aurora (HA: 1 replica to write, 3 others to read) as their MySQL implementation for the demo.

They did not supply a JDBC string to their Spring Boot application, but rather a specific cloud.aws.rds.instance property in their application.yaml; further Aurora and IAM support are coming soon to not provide credentials.

Then they moved onto messaging with AWSSimpleQueue, using a Spring QueueMessagingTemplate and a @SqsListener annotation; similarly they demo’ed SNScommunications to send HTTP requests to several services at once.

In a second part of the presentation, they introduced the AWSParameterStore and SecretManager.

AWSParameterStore is a highly available (sync’ed across regions and zones) ParameterStore; Spring Cloud allows you to read your application properties directly from it (instead of a local application.properties file)

AWSSecretmanager is the ParameterStore equivalent, but for secrets / credentials; interestingly enough you mount SecretManager exactly the same way as you mount ParameterStore – secret rotation support is coming to .Spring Cloud soon

Other services covered by Spring Cloud but were not shown during the presentation: Elastisearch, etc.

If Spring Cloud AWS is not enough, you can still use the AWS SDK for Java.

To test your services relying on AWS Services, you can use LocalStack that runs as a container on your local machine – even better, you can pilot LocalStack through TestContainers in your tests.

Spring Cloud AWS 3.x is coming and will bring support for AWS SDK v2 (huge work), some support will be dropped (such as Elasticache since the regular Redis suport is already good enough), and GraalVM Native image compatibility.

The best way to get started is through Spring Cloud AWS samples, and via the reference documentation at https://awspring.io/

Other interesting talks

Ingress? That’s So 2020! Introducing the Kubernetes Gateway API, by Abhinav Rau and Madhav Sathe

The Kubernetes Ingress is stuck between the LoadBalancer and the Services of a Deployment (/v1 and /v2 for example)

The Gateway API adds features and decouple the roles of the platform admin (GatewayClass) and the developers (HTTPRoutes); so that the cluster administrator will not imped the application developers to manage the routing to their services themselves.

Spring Cloud Function: Where We Were, Where We Are, and Where We’re Going, Marc DiPasquale, Solace Mark Sailes, Oleg Zhurakousky

Spring Cloud Function core features: composition (func1|func2), reactive support (Flux), if it looks like a function, it will be considered as a function.

Leveraging Standard Buildpacks to Migrate Not-So-Standard Apps by Brandon Blincoe and Matthew Campbell

After a brief introduction about the difficulty of moving to micro services, the presenters introduced us to buildpacks.

As an example of complex migration, they took an app written in Perl based on Apache HTTP server, and they first tried to trigger a builpack build with cf push , it failed so they searched on Github a community custom perl buldpack, it did not work and that was not a safe approach anyway to rely on some random buildpack – so during the demo they did some trial and error to make their own Apache with Perl buildpack.

Nice tools mentioned or used during talks

httpie : a nice replacement for curl (install using brew install httpie)

octotree: a nice side panel to navigate github keeping the tree structure visible, install via your browser extensions manager

k9s: a terminal based k8s client that provides a GUI like experience (install using brew install k9s)

Carvel tooling: tool to bundle images + manifest to a remote registry (harbor) – think of a remote deployment site with limited connectivity

tilt: competitor to Skaffold for local environment deployment to Kubernetes (you save your classes and it triggers an image build and a dpeloyment to k8s)