Quarkus — Cheat Sheet

Tag: quarkus, java, framework, kubernetes, graalvm, microservices, cloud-native, aot

Livello: intermedio

TL;DR: Framework Java cloud-native e Kubernetes-native, ottimizzato per GraalVM e OpenJDK. Offre tempi di avvio rapidissimi e basso consumo di memoria grazie alla build-time initialization.

Concetti chiave

Architettura container-first: ottimizzato per minimizzare l'impronta di memoria (RSS) e avviare i container in pochi millisecondi.

Build-time initialization: sposta il lavoro di reflection, parsing XML/JSON e dependency injection dalla fase di startup a quella di build (AOT).

GraalVM Native Image: permette di compilare l'applicazione in un eseguibile nativo specifico per il sistema operativo target.

Paradigma unificato: supporta nativamente e contemporaneamente il modello di programmazione bloccante (imperativo) e non bloccante (reattivo).

Developer Joy: live coding integrato e continuo (hot reload) con il comando di sviluppo senza necessità di riavviare manualmente.

Supporto standard: implementa specifiche MicroProfile (JAX-RS, CDI) ma offre anche layer di compatibilità per API Spring (DI, Web, Data).

Ecosistema estensioni: architettura a plugin dove ogni libreria supportata è pre-ottimizzata e configurata per la compilazione nativa.

Hibernate con Panache: strato di semplificazione per il data access layer che implementa nativamente i pattern Active Record e Repository.

Domande tipiche e risposte pronte

Q: Qual è la differenza principale tra Quarkus e Spring Boot tradizionale?R: Quarkus sposta la maggior parte del setup, reflection e proxy generation a build-time, garantendo un avvio istantaneo, mentre Spring Boot esegue questo lavoro a runtime.

Q: Cos'è Panache in Quarkus?R: È un layer costruito sopra Hibernate ORM che riduce drasticamente il codice boilerplate. Offre a scelta sia il pattern Active Record sia il pattern Repository.

Q: Come viene gestita la programmazione reattiva?R: Sotto il cofano usa il motore di Eclipse Vert.x e la libreria Mutiny, che espone i tipi Uni (singolo risultato asincrono) e Multi (stream di dati).

Insidie e errori comuni

Fallimento della compilazione nativa per uso di reflection: GraalVM elimina il dead code. Le classi usate dinamicamente vanno esplicitamente annotate con @RegisterForReflection.

Confusione tra proprietà build-time e run-time: alcune configurazioni iniettate a build-time diventano immutabili nell'eseguibile nativo e non possono essere sovrascritte da variabili d'ambiente.

Bloccare l'event loop: usare chiamate bloccanti (es. JDBC classico) su un thread reattivo genera eccezioni. È necessario usare il thread pool worker o i driver reattivi.

Snippet e comandi

# Avvio in modalita' sviluppo (hot reload, test continui)
mvn compile quarkus:dev

# Build dell'eseguibile nativo (richiede GraalVM locale o container builder)
mvn package -Pnative

# Aggiungere una estensione al progetto esistente
mvn quarkus:add-extension -Dextensions="hibernate-orm-panache, jdbc-postgresql"

Java

// Esempio Entity usando il pattern Active Record con Panache
@Entity
public class Person extends PanacheEntity {
    public String name;
    public LocalDate birthDate;

    // Metodo custom aggiunto direttamente all'entita'
    public static Person findByName(String name){
        return find("name", name).firstResult();
    }
}

// Esempio Endpoint REST (JAX-RS)
@Path("/persons")
public class PersonResource {
    @GET
    public List<Person> getAll() {
        return Person.listAll();
    }
}

Da ripassare

[ ] Tipi Uni e Multi della libreria Mutiny.

[ ] Configurazione dei profili (dev, test, prod) nel file application.properties.

[ ] Layer di compatibilità Spring API (limitazioni e best practice).

Jarvis Interviews
Jarvis