Unter jedem Quarkus-Service arbeitet die reaktive Vert.x-Engine. Daraus wird oft der Schluss gezogen, man müsse nun alles reaktiv programmieren. Muss man nicht — und sollte man auch nicht überall.
Warum die Engine überhaupt reaktiv ist
Ein Event Loop bedient sehr viele Verbindungen mit wenigen Threads. Das ist der Grund für den hohen Durchsatz. Es ist zugleich die Regel, an der sich alles andere ausrichtet: Blockierende Arbeit gehört nie auf den Event Loop. Ein einziger blockierender Aufruf an der falschen Stelle bremst nicht nur die eigene Anfrage, sondern alle anderen gleich mit.
Zwei Wege, dieselbe Regel
Für nicht-blockierende Abläufe gibt es Mutiny mit Uni und Multi — es
macht asynchrone Ketten lesbar und komponierbar. Für blockierende Aufrufe gibt
es Worker Threads oder, deutlich bequemer, Virtual Threads: reaktiver
Durchsatz bei imperativem, blockierendem Code.
Das ist der eigentliche Punkt: Du entscheidest pro Endpunkt, nicht einmal fürs ganze Projekt. Reaktiv und imperativ liegen im selben Dependency-Paket.
Die Entscheidung ist mechanisch
Nicht-blockierend? Event Loop und Mutiny. Blockierender Datenbank- oder HTTP-Aufruf? Worker oder Virtual Thread. Diese zwei Fragen genügen für die allermeisten Fälle — Framework-Philosophie braucht es dafür nicht.
Mehr dazu im Seminar
Reaktive Muster, Microservice-Bausteine, Observability und der Weg zum Native-Image stehen im Modul Reaktives, Microservices & Deployment.