Jedes Mal wenn ein neuer Kunde fragt, wer die App baut, ist die Backend-Entscheidung der längste Einzelpunkt im Briefing. App-Store-Apps leben Jahre; das Backend dahinter muss jeden Morgen, jedes Release, jedes iOS-Major-Update da sein. Die Frage ist nie was lässt sich schnell schreiben — sondern was ist die nächsten fünf Jahre billig zu betreiben.
Ich lande immer wieder bei Quarkus.
Was Quarkus tatsächlich liefert
Quarkus ist das Java-Framework unter Red Hat, das mit GraalVM zu einer nativen Binary kompiliert. Boot-Zeit 30 Millisekunden, Speicher-Footprint einstellig in MB, Runtime die JVM, der du sowieso vertraust — und die Developer-Experience ist ein Dev-Mode-Hot-Reload, der die meisten Node-Setups in den Schatten stellt.
Für den KMU-Maßstab ist das der Sweet Spot: schnelle Iteration in der Entwicklung, winzige Container-Images in Produktion und das gesamte Jakarta-EE-/SmallRye-Ökosystem an Integrationspunkten, sobald du sie brauchst.
Was es nicht liefert
Es ist nicht umsonst. Quarkus hat eine Lernkurve, wenn du noch nie mit CDI gearbeitet hast. Die Native-Image-Kompilierung ist langsam in der CI. Die GraalVM-Substrate hat gelegentliche scharfe Kanten rund um Reflection. Nichts davon ist ein Deal-Breaker, aber alles ist real.
Wann ich was anderes nehme
Wenn das Team des Kunden zwei TypeScript-Entwickler sind und sie das Backend übernehmen nachdem ich raus bin, schreibe ich es in TypeScript und sie haben Eigentum daran. Tooling-Kontinuität schlägt Benchmark-Zahlen für ein kleines Team.
Bei stark event-getriebenen Workloads greife ich manchmal zu Go — Single-Binary, keine JVM, einfacher zu betreiben für Leute, die schon Go sprechen.
Aber für das Default-Projekt aus „App + Backend”? Quarkus.