Quarkus Schulung: REST, Kafka und reaktives Messaging

Quarkus einordnen und das erste Projekt

• Quarkus neben Spring Boot und Jakarta EE: vertraute Standards, Arbeit zur Build-Zeit
• Imperativ und reaktiv in einem Framework: welches Modell für welche Aufgabe passt
• Startprojekt mit quarkus create app und Extensions für REST, Panache und Messaging
• Im Dev Mode entwickeln: Live Reload, Dev UI und Dev Services für Datenbank und Broker
• Was dieser Einstieg nur streift: Native Image, Beobachtbarkeit und Kubernetes (→ Seminar Quarkus)

Dependency Injection mit ArC

• ArC als CDI-Implementierung: Beans zur Build-Zeit auflösen, Fehler schon beim Build
• ArC und CDI Lite: welche Teile der Spezifikation Quarkus abdeckt
• Injektion per Konstruktor oder Feld – package-private statt private, um Reflexion zu vermeiden
• Scopes und Client-Proxys: @ApplicationScoped gegenüber @Singleton und @RequestScoped
• Ungenutzte Beans entfernen lassen und mit @Unremovable gezielt behalten
• Implementierungen austauschen mit @DefaultBean, @IfBuildProfile und @LookupIfProperty
• Lebenszyklus: @Startup, StartupEvent und ShutdownEvent beobachten

Quarkus konfigurieren

• Werte mit @ConfigProperty injizieren: Standardwerte, Pflichtangaben und Optional
• Zusammengehörige Einstellungen als @ConfigMapping-Interface statt verstreuter Einzelwerte
• Profile für Entwicklung, Test und Produktion; Werte aus Umgebungsvariablen und .env
• Build-Zeit- und Laufzeit-Eigenschaften unterscheiden: was nach dem Build feststeht

Datenzugriff mit Panache

• Datenquelle und Hibernate ORM einrichten, PostgreSQL aus den Dev Services nutzen
• Entities, Transaktionen mit @Transactional und Schemaerzeugung während der Entwicklung
• Panache als Active Record mit PanacheEntity oder als Repository mit PanacheRepository
• Abfragen mit verkürztem HQL, Sortierung und seitenweises Lesen mit page()
• Reaktiver Zugriff mit Hibernate Reactive Panache und @WithTransaction
• Reaktiver PostgreSQL-Client von Vert.x für schlanke Abfragen ohne ORM

REST-Endpunkte mit Quarkus REST

• Jakarta REST (früher JAX-RS) in Quarkus: Ressourcen, @Path und HTTP-Methoden
• Quarkus REST, vormals RESTEasy Reactive, und RESTEasy Classic in Bestandsprojekten
• JSON mit Jackson, Antworten mit RestResponse<T>, Parameter mit @RestQuery
• Threading-Modell: Event-Loop oder Worker-Thread, abhängig von der Signatur der Methode
• Uni und Multi als Rückgabe, Server-Sent Events für fortlaufende Daten
• Endpunkte mit @QuarkusTest und REST Assured gegen die Dev-Services-Datenbank testen

GraphQL mit SmallRye GraphQL

• GraphQL oder REST: wann sich ein Schema mit frei wählbaren Feldern lohnt
• Schnittstelle aus Java-Klassen mit @GraphQLApi, @Query und @Mutation
• Verschachtelte Felder mit @Source und Batching gegen N+1-Abfragen
• Generiertes Schema unter /graphql/schema.graphql und GraphQL UI unter /q/graphql-ui
• Subscriptions mit Multi und typsicherer Client mit @GraphQLClientApi

Reaktiv programmieren mit Mutiny

• Reaktiver Kern von Quarkus: Vert.x, Event-Loop und warum Blockieren dort Durchsatz kostet
• Mutiny-Grundlagen: Uni für genau ein Ergebnis, Multi für Datenströme
• Ketten bauen mit onItem().transform(), transformToUni() und call()
• Fehler und Zeitlimits: onFailure().retry(), recoverWithItem() und ifNoItem()
• Mehrere Aufrufe kombinieren mit Uni.combine() statt sie nacheinander abzuwarten
• Blockierende Bibliotheken einbinden: @Blocking, emitOn() und @RunOnVirtualThread
• Gegendruck bei Multi: Puffern, Verwerfen und Anfordern im eigenen Tempo

Messaging mit SmallRye Reactive Messaging

• Kanäle mit @Incoming und @Outgoing: Nachrichtenflüsse deklarativ beschreiben
• Erweiterungen quarkus-messaging-kafka und quarkus-messaging-amqp, Broker aus Dev Services
• Kafka anbinden: Topics, Consumer-Gruppen und JSON-Serialisierung eigener Typen
• AMQP 1.0 mit einem Broker wie Apache Artemis (vormals ActiveMQ Artemis): Adressen, Warteschlangen, Zustellung
• Konfiguration der Kanäle unter mp.messaging.incoming und mp.messaging.outgoing
• Aus REST-Endpunkten senden mit @Channel und Emitter, Rückmeldung als Uni
• Bestätigen und scheitern: Acknowledgement, Wiederholung und Dead-Letter-Topic
• Langsame Verarbeitung mit @Blocking, Reihenfolge innerhalb einer Kafka-Partition
• Nachrichtenverarbeiter mit dem In-Memory-Connector testen, ohne laufenden Broker

Ereignisse und Observer

• CDI-Ereignisse: Event<T> auslösen und mit @Observes empfangen
• Asynchrone Beobachter mit @ObservesAsync und Reihenfolge über @Priority
• Ereignisse erst nach dem Commit zustellen: TransactionPhase.AFTER_SUCCESS
• Vert.x Event Bus mit @ConsumeEvent für lose gekoppelte Komponenten im Dienst
• Ereignis im Prozess oder Nachricht über Kafka: Kriterien für die Entscheidung

Reaktive Quarkus-Dienste mit Claude Code

• Warnungen über blockierende Aufrufe auf dem Event-Loop als Abnahmekriterium für Agentenänderungen
• await().indefinitely() in vorgeschlagenen Mutiny-Ketten aufspüren und durch Verkettung ersetzen
• Kanalnamen aus @Incoming/@Outgoing und mp.messaging.* vom Agenten gegeneinander abgleichen lassen
• Neue Nachrichtenverarbeiter nur mit Test über den In-Memory-Connector übernehmen
• GraphQL-Schema vor und nach einer Agentenänderung vergleichen und Breaking Changes erkennen

Praxisprojekt: Bestellstatus für einen Getränkelieferdienst

• Bestell-API mit Quarkus REST und Panache, Bestellungen in PostgreSQL aus den Dev Services
• Ereignis „Bestellung angelegt“ über Kafka an einen Lagerdienst, Fehlschläge ins Dead-Letter-Topic
• Statusabfrage per GraphQL, Live-Status für die Fahrer-App als Server-Sent Events mit Multi
• Transaktionsgebundenes CDI-Ereignis stößt nach dem Commit die Kundenbenachrichtigung an

Lernziele

• Sie strukturieren Quarkus-Anwendungen mit ArC-Beans, Scopes und typsicherer Konfiguration
• Sie greifen mit Panache blockierend und reaktiv auf PostgreSQL zu
• Sie entwickeln Endpunkte mit Quarkus REST und eine GraphQL-Schnittstelle mit SmallRye GraphQL
• Sie formulieren asynchrone Abläufe mit Mutiny und behandeln Fehler und Zeitlimits
• Sie verbinden Dienste über Kafka oder AMQP mit SmallRye Reactive Messaging und testen die Verarbeitung ohne Broker
• Sie entscheiden begründet zwischen CDI-Ereignis, Event Bus und Nachricht über einen Broker

Zielgruppe

• Java-Entwickler:innen mit Jakarta-EE- oder Spring-Kenntnissen, die Quarkus kennenlernen
• Entwicklungsteams, die ereignisgetriebene Dienste mit Kafka oder AMQP planen
• Software-Architekt:innen, die das reaktive Modell von Quarkus für ihre Projekte bewerten