Jedes Mal, wenn ein neuer Kunde fragt, wer die App baut, ist die Entscheidung über das Backend der längste Einzelpunkt im Briefing. Apps aus dem App Store leben jahrelang; das Backend dahinter muss jeden Morgen, bei jedem Release und bei jedem großen iOS-Update verfügbar sein. Die Frage lautet nie, was sich schnell schreiben lässt, sondern was in den nächsten fünf Jahren günstig zu betreiben ist.
Ich lande immer wieder bei Quarkus.
Was Quarkus tatsächlich liefert
Quarkus ist das Java-Framework von Red Hat, das sich mit GraalVM zu einer nativen Binärdatei kompilieren lässt. Es startet in 30 Millisekunden, braucht Speicher im einstelligen MB-Bereich und läuft auf der JVM, der Sie ohnehin vertrauen. Dazu kommt ein Dev-Mode mit Hot Reload, der die meisten Node-Setups in den Schatten stellt.
Für die Größenordnung eines KMU passt das genau: schnelles Arbeiten in der Entwicklung, winzige Container-Images in Produktion und das gesamte Ökosystem von Jakarta EE und SmallRye, sobald Sie Anbindungen brauchen.
Was es nicht liefert
Umsonst ist das nicht. Wer noch nie mit CDI gearbeitet hat, muss sich in Quarkus einarbeiten. Die Kompilierung zum Native Image dauert in der CI lange. Und Substrate VM aus GraalVM hat bei Reflection gelegentlich Tücken. Nichts davon ist ein Ausschlussgrund, aber alles davon ist real.
Wann ich etwas anderes nehme
Besteht das Team des Kunden aus zwei TypeScript-Entwicklern, die das Backend übernehmen, wenn ich nicht mehr dabei bin, schreibe ich es in TypeScript, und es gehört dann wirklich ihnen. Für ein kleines Team zählt es mehr, bei den gewohnten Werkzeugen zu bleiben, als bessere Benchmark-Zahlen zu haben.
Bei stark ereignisgesteuerten Lasten greife ich manchmal zu Go: eine einzige Binärdatei, keine JVM und einfacher zu betreiben für Leute, die Go bereits beherrschen.
Aber für das typische Projekt aus App und Backend? Quarkus.