Spring Boot & Spring Reactive

Spring Boot ist ein Framework zur schnellen Entwicklung von Spring-Anwendungen. Es reduziert Konfiguration durch Auto-Configuration und Starter-Abhängigkeiten. Anwendungen sind sofort lauffähig.

Spring ist ein umfassendes Framework. Spring Boot baut darauf auf und vereinfacht Setup und Konfiguration. Es bringt Embedded Server und Konventionen mit.

Auto-Configuration registriert Beans automatisch. Sie basiert auf Classpath-Abhängigkeiten und Properties. Entwickler müssen weniger konfigurieren.

Starter bündeln häufig genutzte Abhängigkeiten. Sie vereinfachen das Dependency-Management. Beispiele sind spring-boot-starter-web oder data-jpa.

Der ApplicationContext ist der zentrale Spring Container. Er verwaltet Beans und deren Lifecycle. Er stellt Dependency Injection bereit.

Abhängigkeiten werden vom Container bereitgestellt. Klassen erzeugen ihre Dependencies nicht selbst. Das verbessert Testbarkeit und Wartbarkeit.

Alle sind Stereotypen für Beans. @Service und @Repository sind semantische Spezialisierungen. @Repository fügt zusätzlich Exception-Übersetzung hinzu.

Damit werden externe Konfigurationen an POJOs gebunden. Die Konfiguration ist typsicher und strukturiert. Sie ersetzt viele @Value-Anwendungen.

Spring MVC ist das imperative Web-Framework. Jede Anfrage blockiert einen Thread. Es eignet sich für klassische Webanwendungen.

WebFlux ist das reaktive Web-Framework von Spring. Es basiert auf nicht-blockierender Verarbeitung. Es eignet sich für hohe Parallelität.

MVC ist blockierend und thread-basiert. WebFlux ist asynchron und event-getrieben. Beide können nicht beliebig gemischt werden.

Reaktives Programmieren arbeitet mit Datenströmen. Es reagiert auf Events statt auf Aufrufe. Ziel ist bessere Skalierbarkeit.

Mono repräsentiert 0 oder 1 Wert. Flux repräsentiert 0 bis n Werte. Beide stammen aus Project Reactor.

Project Reactor ist die reaktive Basisbibliothek von Spring. Sie implementiert den Reactive-Streams-Standard. WebFlux baut darauf auf.

Backpressure steuert den Datenfluss zwischen Producer und Consumer. Konsumenten bestimmen die Geschwindigkeit. Das verhindert Überlastung.

Blocking blockiert Event-Loop-Threads. Das zerstört Skalierungsvorteile. Blocking Code muss ausgelagert werden.

Scheduler steuern die Thread-Nutzung. Beispiele sind elastic oder parallel. Sie helfen bei Thread-Wechseln.

Klassische @Transactional funktioniert nicht immer. Reactive Transaktionen nutzen spezielle APIs. Sie sind expliziter.

Spring Data Reactive unterstützt reaktive Datenzugriffe. Beispiele sind R2DBC oder Reactive MongoDB. JDBC ist nicht reaktiv.

JDBC blockiert Threads. Es unterstützt keine asynchrone Verarbeitung. Daher ist es für WebFlux ungeeignet.

R2DBC ist eine reaktive Datenbank-API. Sie ersetzt JDBC im reaktiven Kontext. Sie ermöglicht nicht-blockierenden Datenzugriff.

@RestController kombiniert @Controller und @ResponseBody. Methoden liefern direkt JSON. Es wird für REST APIs genutzt.

WebFlux nutzt funktionale Error-Handler oder @ControllerAdvice. Fehler werden reaktiv verarbeitet. Der Ansatz unterscheidet sich von MVC.

Actuator stellt Betriebs- und Monitoring-Endpunkte bereit. Beispiele sind health oder metrics. Er unterstützt Observability.

Observability umfasst Metriken Logs und Traces. Spring Boot integriert Micrometer und OpenTelemetry. Das erleichtert Monitoring.

Spring Security bietet reaktive Varianten. Sie sind nicht-blockierend. Klassische Security-Konfigurationen sind nicht kompatibel.

Bei vielen gleichzeitigen Verbindungen. Besonders bei I/O-lastigen Systemen. Nicht bei CPU-lastigen Aufgaben.

Bei klassischen CRUD-Anwendungen. Wenn Blocking kein Problem ist. Es ist einfacher zu verstehen.

Mix aus blocking und non-blocking Code. Falsche Scheduler-Nutzung. Unterschätzung der Komplexität.

Man nutzt WebTestClient. Tests sind nicht-blockierend. StepVerifier wird für Flux und Mono verwendet.