Hola Barcelona, Spring IO 2022
Nach einer Corona Pause kehrte nun endlich die Spring IO, die führende europäische Konferenz zum Spring Framework, als vor Ort Veranstaltung zurück!
Am 26. und 27. Mai fanden sich ca 1.200 Teilnehmer:Innen aus der ganzen Welt zur zweitägigen Konferenz im wunderschönen Barcelona zusammen.
Auch iits-consulting war diesmal mit fünf Entwicklern vertreten, um sich über die neuesten Trends in der Spring-Welt zu informieren sowie mit anderen Entwickler:Innen auszutauschen.
In diesem Blogartikel fassen wir unsere Highlights zusammen:
Spring Framework 6, Spring Boot 3, Native Images
Eines der technischen Highlights im Spring Ökosystem, welches Einzug in Spring Framework 6 und Spring Boot 3 (Veröffentlichung im November 2022) erhält, ist die Möglichkeit, native Images mit GraalVM und Ahead-of-Time Kompilierung zu erzeugen und auszuführen, wodurch sich die StartUp-Zeit einer Spring Boot Applikation auf wenige Millisekunden verringert. Dadurch eröffnen sich neue architektonische Möglichkeiten und Java / Kotlin kann im Serverless Bereich besser mit Sprachen / Plattformen wie Go oder Node.JS konkurrieren.
Native Images bringen diverse Vor- und Nachteile mit sich. Neben der StartUp-Zeit enfällt die WarmUp-Zeit, wie sie normalerweise bei Just-in-Time Kompilierung anfällt. Zudem verringert sich der Speicherverbrauch zur Laufzeit. Dies geht allerdings mit einer leicht verringerten Peak-Performance einher. Die verbesserten Laufzeit-Eigenschaften erhält man allerdings nicht kostenlos. Zum einen erhöht sich die Zeit für die Kompilierung des Images erheblich. Zum anderen können native Images nicht immer automatisch erzeugt werden. Dies liegt daran, dass reflektive Aufrufe und dynamik Proxies konfiguriert werden müssen. Diese Konfigurationen werden per statischer Analyse zur Kompilierungszeit teilweise aus dem Code generiert, müssen aber in manchen Fällen mit Hilfe einer neuen API definiert werden.
Im Rahmen der neuen Major Releases von Spring Framework und Spring Boot werden auch weitere Weichen für die Zukunft gestellt. Als Baseline JVM Version wird 17 gesetzt, was für manche Enterprise Kunden mit Sicherheit noch herausfordernder sein dürfte. Schließlich wurden im August 2021 noch sehr viele Applikationen in Produktion auf JVMs der Version 8 betrieben, wie Umfragen zeigen. Des weiteren wird auf neuere jakarta APIs umgestellt, um Tomcat 10+ oder Jetty 11+ nutzen zu können.
Solange man keine Frameworks oder Libraries entwickelt, sollten diese Änderungen allerdings sehr einfach mit Search/Replace in der IDE gelöst werden können. Mit Hilfe dieser Neuerungen will man besser vorbereitet sein auf die großen anstehenden Änderungen im JVM Bereich, wie z. B. Projekt Loom mit dem neuen Concurrency Model oder Projekt Leyden, das statische Images auch auf die JVM bringen wird.
Passwordless Logins mit Spring Authorization Server und WebAuthn
Einer der angebotenen Workshops handelte von passwortloser Authentifizierung und wurde von Abid Saikali gehalten. Dabei wurden die FIDO Alliance und die WebAuthn API vorgestellt. Die FIDO Alliance ist ein Bündnis von Firmen wie Google, Meta, Apple, Microsoft, vmware, yubico, mastercard, PayPal untere vielen anderen, die gemeinsam Standards entwickeln, welche die sichere Benutzer-Authentifizierung ohne Passwörter ermöglichen. Zur Nutzung der WebAuthn-API werden Libraries für verschiedene Programmiersprachen (z.B. Java, Vue.js, Express.js), Plattformen (z.B. iOS und Android), und Frameworks (z.B. Spring Boot, Express.js) bereitgestellt, um die Umsetzung der FIDO Standards schnell und sicher zu gewährleisten.
Einer der größten Vorteile der passwortlosen Authentifizierung mit z. B. mit Fingerprint-Sensoren, Face-ID, Yubikeys ist, dass sie besser gegen Fishing Attacken abgesichert ist als viele andere Methoden der Authentifizierung.
Als Fun Fact: Apple hat in der vergangene Woche ein neues Feature namens “Passkey” vorgestellt, was genau ihre Umsetzung der FIDO Standards für die Apple Plattformen darstellt. Spring Boot ist durch vmwares Engagement in der FIDO Alliance keinen Schritt dahinter. Als Entwickler:Innen können wir mit dem Spring Authorization Server unseren Benutzer:Innen diese Art des Logins und der Authentifizierung ebenso in unseren Applikationen anbieten.
Getting modules right with Domain-driven Design
Serviceorientierte Architektur, insbesondere Microservices, sind aus der modernen Softwareentwicklung wohl oder übel nicht mehr wegzudenken. Ein wichtiger Aspekt bei einer solchen Architektur ist, wie die Services geschnitten werden: schlecht geschnittene Services erhöhen den Overhead, sowohl in der Kommunikation zwischen den Services als auch in den Köpfen der Entwickler.
Domain-driven Design (DDD) verspricht hier Abhilfe. Michael Plöd von INNOQ präsentierte in seiner Session verschiedene Werkzeuge aus dem Bereich DDD. Wohingegen sich die klassische objektorientierte Analyse und Design zuerst auf Nomen und ihre Attribute fokussiert, steht bei DDD das Verb im Mittelpunkt.
Als Verfahren wurde Event Storming vorgestellt. Event Storming ist ein workshopbasiertes Verfahren, bei dem Domänen- und technische Experten zusammen Domänenevents ermitteln, einem Kommando zuordnen und schließlich gruppieren. Die Methode fördert zudem eine gemeinsamen Sprache zwischen den technischen Teams und den anderen Stakeholdern. Die Slides zum vollständigen Vortrag finden sich hier.
Bye bye layered architecture
Rest. Business. Persistence. Jeder der anwesenden Entwickler:Innen kennt diese simple Architektur. Bei den Fortgeschrittenen liegt diese Dreiteilung noch innerhalb eines fachlichen Slices. Verflechtungen zwischen den Slices und eine oft unpassende Top-Level-Granularität waren allerdings auch Schmerzpunkte, die allen Anwesenden nur zu gut bekannt sind.
So ist es nicht verwunderlich, dass auch alternative Architekturen ein wichtiger Bestandteil dieser Konferenz waren. Einen besonders simplen und eleganten Ansatz präsentierte Tim Zöller: Überspringe das Business-Layer.
Gerade bei simpleren Anwendungen wird oft grundlos eine Entity in ein Business-Objekt transformiert, dieses dann zu einem Repräsentations-Objekt transformiert bevor es im Rest-Layer zurückgegeben wird. Der bessere Ansatz wäre, die Repositorys aus dem Rest-Layer heraus anzusprechen, die Ergebnisse in eine passende Projektion zu schreiben und diese direkt zurückzugeben.
Eine deutlich radikalere und allgemeinere Alternative präsentierte Tom Hombergs in seinem Vortrag Let’s build components, not layers. Die gesamte Anwendung wird aus modularen Komponenten aufgebaut. Dabei ist vereinfacht gesagt eine Komponente definiert durch ihre API und die interne Logik. Die API definiert die zugängliche Funktionalität und ist von außen bedienbar. Die interne Logik implementiert die Funktionalität und kann aus weiteren Komponenten bestehen. Nur die API der eigenen Komponente darf auf die jeweilige interne Logik zugreifen.
Im Detail existieren noch weitere Regeln, für die wir hier allerdings auf den Vortrag verweisen wollen. Das Ergebnis dieser ausgeklügelten Architektur ist jedoch eine starke Isolation zwischen den Modulen, die dazu führt, dass man einzelne Module sehr aufwandsarm austauschen oder für einen eigenen Microservice heraustrennen kann.
