Agile Coding mit Java, Kotlin, Spring und Microservices

Im 2. Teil meines Spring MVC mit Thymeleaf Artikels geht es um: html Formulare und JavaScript in Templates, Wiederverwendung gleicher html-Blöcke in Thymeleaf und der Internationalisierung (I18N) von Spring Web-Anwendungen. Spring Model-View-Controller mit Thymeleaf und POJOs Den 1. Teil meines Spring MVC mit Thymeleaf Artikels findet ihr hier und auf YouTube: https://agile-coding.blogspot.com/2020/10/spring-mvc-thymeleaf.html Den kompletten Code zu Teil 1 & 2 gibt es hier bei GitHub: https://github.com/elmar-brauch/thymeleaf Wiederverwendung von gemeinsamen html Blöcken Das berühmte Clean Code Prinzip ( Clean Code von Robert Martin ) "Don't repeat yourself" gilt nicht nur für Java-Code. Es gilt für alle selbst geschriebenen Artefakte. Wenn wir für 10 verschiedene html Seiten Thymeleaf Templates erstellt haben, sollten wir unbedingt vermeiden per Copy & Paste den Header, Footer oder ähnliches überall zu duplizieren. Damit wir es nicht an 10 Stellen anpassen müssen

Hat eure Anwendung Probleme mit langsamen Zugriffen auf Datenbanken oder andere Content liefernde Medien? Dann kann ein Cache mit Hilfe der schnellen In-Memory NoSQL Datenbank Redis helfen. Verwendet Spring Data und Spring Cache, dann müsst ihr nicht im Detail verstehen wie Redis funktioniert. Überblick Cache und Redis Cache Ein Cache wird immer zwischen eine Anwendung oder einen Client und ein Hintergrundmedium (z.B. eine Datenbank oder ein Laufwerk) geschaltet. Vereinfacht gesagt, speichert der Cache die Daten, die vom Hintergrundmedium abgefragt wurden, so dass beim nächsten Zugriff auf dieselben Daten, die Auslieferung aus dem Cache erfolgt. Ein Cache ist für die besonders schnelle Auslieferung seiner Daten optimiert. Dadurch bekommt die Anwendung oder der Client schnellere Antworten vom Cache im Vergleich zu den langsamen Antworten des Hintergrundmediums. Das folgende Schaubild zeigt wie eine Spring Anwendung eine MongoDB als Hintergrundmedium verwendet und die abgefragten Daten i

Ein angenehmer Aspekt von Microservices ist, dass ihre Entwicklung häufig auf der grünen Wiese startet. Ein neuer Microservice ist also immer eine Chance einen neuen Technologie-Stack auszuprobieren. Für eingefleischte Java-Entwickler bietet sich dazu die Programmiersprache Kotlin an.  Als JVM basierte Programmiersprache kann Kotlin problemlos das bei Java-Entwicklern beliebte Spring Framework verwenden. Daher zeige ich in diesem Artikel, wie ihr mit Spring Boot schnell einen Kotlin Microservice mit REST-API aufsetzt. Neuer Microservice, die Gelegenheit mit Kotlin anzufangen... In meinem beruflichen Umfeld entwickeln wir deutlich häufiger neue Microservices als neue Systeme mit klassischen Software-Architekturen oder als Monolithen. Da sich Microservices auf eine Geschäfts-Capability konzentrieren, siehe auch https://www.martinfowler.com/microservices , ist ihre Codebase im Vergleich zu herkömmlichen Systemen meist deutlich kleiner. Die Situation, einen neuen Microservice auf der grüne

Web-Anwendungen mit Zuständen sind häufig aufgrund der benötigten Session kein leichtes Thema. Daher gibt es im Spring Framework das Projekt Spring Session, welches uns ohne großen Aufwand die Daten der Session vom Application Server auslagert, so dass wir unsere Web-Anwendung clustern können. Hier werde ich zeigen, wie einfach ihr Spring Session in eurer Spring Boot Projekt einbinden könnt. Spring Session in Spring Boot Projekten integrieren In einem anderen Blog-Artikel habe ich eine Web-Anwendung mit Thymeleaf gebaut. In dieser Anwendung wurde die Session bisher weder benutzt noch persistiert, so dass die Daten des Benutzers nach einem Anwendungsneustart oder Serverwechsel im Cluster weg waren. Spring Boot ermöglicht uns dank vorbereiteter Default-Konfiguration das Integrieren einer persistenten Session in 2 Schritten. Diese werde ich euch hier mit MongoDB als Datenbank zum Persistieren der Session zeigen. Neben der MongoDB kann die Session auch in einer JDBC basierten Datenbank, R

Automatisiertes Testen von Spring Beans kann anfangs schwierig sein. Daher zeige ich euch in diesem Artikel, wie ihr die typischen Herausforderungen beim Testen von void-Methoden, Datenbank- und Backend-Interaktionen mit Spring Boot und Mockito in den Griff bekommt. Unit-Tests mit dem Mockito Mock-Framework Wenn wir in einer Klasse oder Spring Bean Methoden haben, die eine Datenbank oder die Verfügbarkeit eines Backends benötigen, ist das für Unit-Tests ein Problem. Unit-Tests konzentrieren sich immer auf die kleinste Einheit und die schließt Datenbanken und Backends aus. Um solche Methoden trotzdem Testen zu können, gibt es Mocks. Ein Mock ersetzt die Datenbank oder das Backend und liefert von uns vorbereitete Testdaten zurück. Weitere Infos zu Mocks findet ihr hier: https://de.wikipedia.org/wiki/Mock-Objekt Mockito ist eines der beliebtesten Mock-Frameworks für Java oder Kotlin und bietet eine einfache API zum Erstellen, Konfigurieren und Interagieren mit Mocks an. Daher wird Mockito