В каких backend-проектах Quarkus является сильным выбором, а где лучше выбрать более простой или другой стек?

Пример: минимальный REST-сервис на Quarkus

// pom.xml: quarkus-resteasy-reactive + quarkus-hibernate-orm-panache
@Path("/items")
@ApplicationScoped
public class ItemResource {

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public List<Item> list() {
        return Item.listAll(); // Panache ActiveRecord
    }

    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    @Transactional
    public Response create(Item item) {
        item.persist();
        return Response.status(201).entity(item).build();
    }
}

Запуск в dev-режиме с live reload:

./mvnw quarkus:dev
# или через CLI:
quarkus dev

Сборка нативного бинарника:

./mvnw package -Pnative -Dquarkus.native.container-build=true
# Результат: target/*-runner (ELF, ~50 МБ, старт ~30 мс)

Когда Quarkus — правильный выбор

Quarkus проектировался для Kubernetes и serverless: он компилируется в нативный бинарник через GraalVM Native Image, стартует за десятки миллисекунд и потребляет в 5–10 раз меньше памяти, чем классическое JVM-приложение. Это делает его отличным решением в следующих сценариях:

• Микросервисы в Kubernetes — быстрый старт сокращает время раскатки при rolling update и HPA-скейлинге. Под каждый сервис не нужна «прогретая» JVM на сотни МБ.
• Serverless / AWS Lambda, Knative — cold-start критичен; нативный бинарник Quarkus укладывается в 20–50 мс против 2–5 с у стандартного Spring Boot.
• CLI-утилиты и batch-задачи — расширение quarkus-picocli даёт полноценный DI в консольном приложении без overhead JVM.
• Event-driven сервисы — интеграция с Kafka через SmallRye Reactive Messaging поддерживает реактивную модель без Reactor/WebFlux.
• Команды с опытом Jakarta EE / MicroProfile — Quarkus реализует CDI, JAX-RS, MicroProfile Config/Health/Metrics, поэтому переход минимален.

Когда лучше выбрать другой стек

• Богатая Spring-экосистема нужна прямо сейчас — Spring Boot имеет зрелые стартеры для сотен интеграций (Batch, LDAP, AMQP и т.д.), которых в Quarkus пока нет или они в экспериментальном статусе.
• Команда знает только Spring — Quarkus требует понимания CDI (а не Spring DI), а некоторые аннотации ведут себя иначе. Кривая обучения есть.
• Native Image несовместим с используемыми библиотеками — рефлексия, dynamic proxy, агенты (например, некоторые legacy JDBC-драйверы) могут не работать без ручной конфигурации GraalVM. Если вы работаете только в JVM-режиме, преимущество Quarkus над Spring Boot существенно меньше.
• Монолит с большой командой — Spring Boot + Spring Data + Spring Security имеют огромную базу знаний, StackOverflow-покрытие и корпоративную поддержку.
• Python/Go/Node.js уже используются — если сервис I/O-bound и несложный, Go net/http или FastAPI дадут аналогичную производительность без JVM.

Подводные камни

• Native Image — не серебряная пуля: компиляция занимает 3–10 минут и требует 6–12 ГБ RAM. В CI это значительный overhead.
• Рефлексия требует явной регистрации: библиотеки, использующие рефлексию (Jackson, MapStruct, JAXB), нужно аннотировать @RegisterForReflection или прописывать в reflection-config.json.
• CDI — не Spring DI: Quarkus использует Arc (подмножество CDI 2.0). @Inject работает только в managed beans; инициализация в конструкторе без @Inject не триггерит DI.
• Dev Services требуют Docker на хосте: при quarkus:dev автоматически поднимаются Postgres/Redis/Kafka через Testcontainers — это удобно, но если Docker недоступен, билд падает с неочевидной ошибкой.
• Не все расширения поддерживают native: всегда проверяйте статус расширения на quarkus.io/extensions — поле «Native» может быть «Preview» или «Experimental».
• JVM-режим теряет главное преимущество: если нативная сборка не нужна, Spring Boot/Micronaut часто выигрывают по экосистеме и зрелости при одинаковых показателях в JVM.
• Блокирующий код в реактивном контексте: JAX-RS-методы по умолчанию выполняются на worker thread, но если вы смешиваете Mutiny и блокирующие вызовы без @Blocking, получите thread starvation.

• Выбирать Quarkus по популярности, а не по требованиям проекта
• Игнорировать опыт команды, эксплуатацию и стоимость поддержки
• Не называть ситуации, где Quarkus будет плохим выбором

• Называет критерии выбора Quarkus
• Учитывает команду, эксплуатацию, стоимость и риски
• Может назвать сценарии, где выбрал бы альтернативу