Springboot

Build und Auslieferung einer Vue-App: dist/, nginx und Deep Links

Die Web-App des Mitfahrlabors soll unter einer festen Adresse der Schule laufen, ohne Node.js auf dem Server. Der Artikel liest die Ausgabe von npm run build und erklärt, warum Umgebungsvariablen beim Bauen festgeschrieben werden und warum Neu laden auf /angebote/1 ohne passende Server-Regel mit 404 endet. Ausgeliefert wird mit nginx: statische Dateien, ein Proxy für die API, ein Fallback für Deep Links und Cache-Header, die zu den Dateinamen mit Hash passen. Als Variante liefert das Backend die App aus static/ aus.

Das Build-Tool Gradle

Gradle baut Java-Projekte über einen Graphen aus Tasks, der nur das ausführt, was sich geändert hat. Der Artikel richtet Gradle mit Wrapper ein, baut ein Hello-World-Projekt ganz ohne Abhängigkeiten, erklärt den Task-Graphen des Java-Plugins und zeigt an einem Spring-Boot-Dienst, wie Stilprüfung, Unit-Tests, eine eigene Suite für Integrationstests und die Abdeckungsprüfung in den Task check eingehängt werden.

Change Request: Live-Aktualisierung mit Server-Sent Events

Mitten im Projekt wünscht sich die Schule, dass sich die Liste der Fahrten von selbst aktualisiert. In Extreme Programming ist ein solcher Änderungswunsch kein Störfall: Das Team schreibt ihn als Karte auf, schätzt ihn nach einem Spike und plant neu. Der Artikel vergleicht Polling, Server-Sent Events und WebSocket, baut im Backend mit SseEmitter einen Ereignisstrom, der erst nach dem Commit sendet, und lässt die Vue-App mit EventSource still neu laden. Dazu kommen Verbindungsabbrüche, nginx, Tests und die Regression über alle bisherigen Tests.

Übungsaufgaben zur Live-Aktualisierung mit Server-Sent Events: Mitfahrgesuche live anzeigen

Die Web-App des Mitfahrlabors aktualisiert die Fahrtenliste inzwischen live. In diesen Übungen baust Du dasselbe für die Mitfahrgesuche: zuerst in Vue mit einem kleinen Refactoring und einem Komponententest, dann im Backend mit SseEmitter und MockMvc. Danach findest Du anhand von Symptomen heraus, warum die Live-Aktualisierung nach Funklöchern, Server-Neustarts und hinter nginx versagt, machst sie robust und wägst für neue Wünsche der Schule Polling, Server-Sent Events, WebSocket und Push ab.

Übungsaufgaben zu Robustheit und Betrieb: Störungsseite und Logs für die Mitfahrgesuche

Auch die Seite der Mitfahrgesuche soll eine Störung überstehen, ohne technische Fehlermeldungen zu zeigen. In diesen Übungen ordnest Du Log-Meldungen den passenden Stufen zu und sagst voraus, welche Meldungen erscheinen, schreibst einen @ControllerAdvice mit Störungsseite und Tests für die Gesuche und rekonstruierst aus Log und Health-Abfragen, was bei einer Störung am Montagmorgen passiert ist.

Robustheit und Betrieb: Fehlerseiten, Actuator und Logging für den Flurmonitor

Ein Neustart der Datenbank genügt, und der Flurmonitor zeigt eine „Whitelabel Error Page“, ein falsch eingerichteter Monitor sogar JSON. In diesem Artikel wird der Monitor robust: Eigene Fehlerseiten ersetzen die Seiten von Spring Boot, und ein @ControllerAdvice zeigt bei einer Störung einen verständlichen Hinweis. Logging mit SLF4J hält fest, was passiert ist, Spring Boot Actuator meldet über /actuator/health, ob die Anwendung läuft. Ein Pipeline-Job prüft die Templates mit dem Nu Html Checker, und das Team schließt Sprint 2 mit Review und Retrospektive ab.

Ein Flurmonitor mit Thymeleaf: das Projekt im Überblick

In zwölf Artikeln bekommt das Mitfahrlabor-Backend eine erste Oberfläche: einen Flurmonitor, dessen HTML-Seiten der Server selbst mit der Template-Engine Thymeleaf erzeugt. Das Team arbeitet dabei nach Scrum in drei Sprints und prüft den Monitor auf allen Testebenen bis zur Abnahme. Hier findest Du den Fahrplan, die Voraussetzungen und die Einordnung ins Backend.

Daten speichern mit Spring Data JPA: Entities, Beziehungen, Repositories und H2

Bisher stehen die Haltepunkte fest im Code, und neue Angebote verschwinden beim Neustart. Jetzt bekommt das Mitfahr-Backend eine Datenbank: Aus dem Fachmodell werden JPA-Entities mit Beziehungen, Spring Data erzeugt den Zugriff aus einem leeren Interface, Hibernate legt die Tabellen an, und eine data.sql füllt die H2-Datenbank beim Start mit den Daten des Szenarios. Wer Docker nutzt, startet dieselbe Anwendung mit MariaDB.

Qualität im Build und eine CI-Pipeline: Checkstyle, Spotless, JaCoCo und GitLab CI

Tests helfen nur, wenn sie auch laufen. Der Build des Mitfahrlabors bekommt drei Prüfwerkzeuge: Checkstyle prüft Regeln für den Code, Spotless sorgt für einheitliche Formatierung, JaCoCo misst die Testabdeckung. Alle hängen an der Sammelaufgabe check (Gradle) bzw. der Phase verify (Maven). Eine Pipeline in GitLab CI führt bei jedem Push die Stufen build, test, quality und package aus und zeigt Testergebnisse und Abdeckung im Merge Request.

Fachlogik in reinem Java: Komponententests für Kostenbeitrag, Einwilligung und Buchungsstatus

Die Regeln, die der API-Vertrag nicht ausdrücken kann, kommen ins Paket domain: der Kostenbeitrag je Kilometer, die Einwilligung bei Minderjährigen und die erlaubten Wechsel des Buchungsstatus. Sie entstehen in reinem Java ohne Spring, mit BigDecimal, LocalDate, einem switch-Ausdruck und eigenen Exceptions. Mit Äquivalenzklassen und Grenzwerten findest Du die Testfälle und prüfst sie mit parametrisierten JUnit-Tests: die erste Testebene des V-Modells, der Komponententest.

Vom Vertrag zum Code: Schnittstellen mit dem OpenAPI Generator erzeugen

Der OpenAPI Generator macht aus dem API-Vertrag Java-Schnittstellen und Datenklassen. Du bindest ihn in Gradle oder Maven ein, lässt den Controller für die Haltepunkte die erzeugte Schnittstelle implementieren und siehst, wie die Regeln aus dem Vertrag als Bean Validation fehlerhafte Anfragen mit 400 abweisen. Weicht der Code vom Vertrag ab, merkt es der Compiler; ist der Vertrag fehlerhaft, bricht der Build ab.

Das Projekt anlegen: der erste Endpunkt für das Mitfahrlabor-Backend

Mit dem Spring Initializr entsteht das Projekt für das Mitfahrlabor-Backend. Du lernst die Projektstruktur, den Build mit Gradle oder Maven und die Startklasse kennen, schreibst den ersten REST-Controller für die Haltepunkte von Hand, rufst ihn mit dem Browser, einer .http-Datei oder der Shell auf und lässt den ersten Test laufen: einen Smoke-Test, der prüft, ob die Anwendung überhaupt startet.

Vom Auftrag zur API: Anforderungen und OpenAPI-Vertrag für das Mitfahrlabor-Backend

Bevor die erste Zeile Java entsteht, wird geplant: Aus dem Auftrag werden User Stories mit Abnahmekriterien, aus den Fachregeln ein Fachmodell mit Zustandsdiagramm, aus der Architektur ein Schichtenmodell und aus allem zusammen ein API-Vertrag im Format OpenAPI. Damit ist die linke Seite des V-Modells für das Mitfahrlabor-Backend vollständig, und jede spätere Testebene weiß, wogegen sie prüft.

Ein REST-Backend mit Spring Boot: das Projekt Mitfahrlabor

In zwölf Artikeln entsteht mit Spring Boot das Backend der Mitfahr-App Mitfahrlabor: von den Anforderungen über den OpenAPI-Vertrag bis zur fertigen REST-API. Dabei durchläufst Du jede Testebene des V-Modells einmal, und eine CI-Pipeline wächst mit. Hier findest Du den Fahrplan, die Voraussetzungen und den Überblick über das, was am Ende entsteht.