Hola Barcelona, Spring IO 2022
After a corona break, Spring IO, the leading European conference on the Spring Framework, finally returned as an on-site event!
On May 26 and 27, around 1,200 participants from all over the world came together for the two-day conference in beautiful Barcelona.
This time, iits-consulting was also represented by five developers to find out about the latest trends in the Spring world and to exchange ideas with other developers.
In this blog article, we summarize our highlights:
Spring Framework 6, Spring Boot 3, Native Images
One of the technical highlights in the Spring ecosystem, which will find its way into Spring Framework 6 and Spring Boot 3 (release in November 2022) is the ability to create and execute native images with GraalVM and ahead-of-time compilation, which reduces the startup time of a Spring Boot application to a few milliseconds. This opens up new architectural possibilities and allows Java / Kotlin to better compete with languages / platforms such as Go or Node.JS in the serverless area.
Native images have various advantages and disadvantages. In addition to the startup time, the warmup time normally required for just-in-time compilation is eliminated. Memory consumption at runtime is also reduced. However, this is accompanied by a slight reduction in peak performance. However, the improved runtime properties do not come for free. On the one hand, the time required to compile the image increases considerably. Secondly, native images cannot always be generated automatically. This is because reflective calls and dynamic proxies have to be configured. These configurations are partly generated from the code by static analysis at compile time, but in some cases they have to be defined with the help of a new API.
The new major releases of Spring Framework and Spring Boot also set the course for the future. The baseline JVM version is 17, which is likely to be even more challenging for some enterprise customers. After all, in August 2021, many applications were still in production on JVMs of version 8 as surveys show. Furthermore, there will be a switch to newer jakarta APIs in order to be able to use Tomcat 10+ or Jetty 11+.
However, as long as no frameworks or libraries are developed, these changes should be very easy to solve with Search/Replace in the IDE. With the help of these innovations, the aim is to be better prepared for the major upcoming changes in the JVM area, such as Project Loom with the new concurrency model or Project Leydenwhich will also bring static images to the JVM.
Passwordless logins with Spring Authorization Server and WebAuthn
One of the workshops offered dealt with passwordless authentication and was held by Abid Saikali. The FIDO Alliance and the WebAuthn API were presented. The FIDO Alliance is an alliance of companies such as Google, Meta, Apple, Microsoft, vmware, yubico, mastercard, PayPal and many others. many otherswho jointly develop standards that enable secure user authentication without passwords. To use the WebAuthn API, libraries are provided for various programming languages (e.g. Java, Vue.js, Express.js), platforms (e.g. iOS and Android) and frameworks (e.g. Spring Boot, Express.js) to ensure that the FIDO standards are implemented quickly and securely.
One of the biggest advantages of passwordless authentication with e.g. fingerprint sensors, Face ID, Yubikeys is that it is better protected against fishing attacks than many other authentication methods.
Fun fact: Apple introduced a new feature last week called "Passkey", which is exactly their implementation of the FIDO standards for the Apple platforms. Spring Boot is not a step behind due to vmware's involvement in the FIDO Alliance. As developers, we can also offer our users this type of login and authentication in our applications with the Spring Authorization Server.
Getting modules right with domain-driven design
For better or worse, service-oriented architecture, especially microservices, have become an integral part of modern software development. An important aspect of such an architecture is how the services are cut: poorly cut services increase the overhead, both in the communication between the services and in the minds of the developers.
Domain-driven design (DDD) promises to help here. In his session, Michael Plöd from INNOQ presented various tools from the field of DDD. Whereas classic object-oriented analysis and design focuses first on nouns and their attributes, DDD focuses on the verb.
Event Storming was presented as a method. Event storming is a workshop-based process in which domain and technical experts work together to identify domain events, assign them to a command and finally group them. The method also promotes a common language between the technical teams and the other stakeholders. The slides for the full presentation can be found here.
Bye bye layered architecture
Rest. Business. Persistence. Each of the developers present is familiar with this simple architecture. For the advanced developers, this tripartite division is still within a functional slice. However, interdependencies between the slices and an often inappropriate top-level granularity were also pain points that all those present were only too familiar with.
It is therefore not surprising that alternative architectures were also an important part of this conference. A particularly simple and elegant approach was presented by Tim Zöller: skip the business layer.
Especially in simpler applications, an entity is often transformed into a business object for no reason, which is then transformed into a representation object before it is returned in the rest layer. The better approach would be to address the repositories from the rest layer, write the results in a suitable projection and return these directly.
Tom Hombergs presented a much more radical and general alternative in his lecture Let's build components, not layers. The entire application is built from modular components. In simple terms, a component is defined by its API and internal logic. The API defines the accessible functionality and can be operated from the outside. The internal logic implements the functionality and can consist of other components. Only the API of its own component may access the respective internal logic.
There are further rules in detail, for which we would like to refer you to the presentation. However, the result of this sophisticated architecture is a strong isolation between the modules, which means that individual modules can be exchanged with very little effort or separated out for a separate microservice.
