Введение


Седьмого марта компания RedHat (вскоре — IBM) представила новый фреймворк — Quarkus. По словам разработчиков, этот фреймворк базируется на GraalVM и OpenJDK HotSpot и предназначен для Kubernetes. Стек Quarkus включает в себя: JPA/Hibernate, JAX-RS/RESTEasy, Eclipse Vert.x, Netty, Apache Camel, Kafka, Prometheus и другие.


Цель создания — сделать Java лидирующей платформой для развертывания в Kubernetes и разработки serverless приложений, предоставляя разработчикам унифицированный подход к разработке как в реактивном, так и в императивном стиле.


Если смотреть на эту классификацию фреймворков, то Quarkus где-то между "Aggregators/Code Generators" и "High-level fullstack frameworks". Это уже больше, чем агрегатор, но и до full-stack не дотягивает, т.к. заточен на разработку backend.


Обещана очень высокая скорость запуска приложения и небольшой расход памяти. Вот данные с сайта разработчика:


Время от старта до первого ответа (с):


Конфигурация REST REST+JPA
Quarkus+GraalVM 0.014 0.055
Quarkus+OpenJDK 0.75 2.5
Traditional Cloud Native Stack* 4.3 9.5

Потребление памяти (Mb):


Конфигурация REST REST+JPA
Quarkus+GraalVM 13 35
Quarkus+OpenJDK 74 130
Traditional Cloud Native Stack* 140 218

Впечатляюще, не так ли?


*Информации об этом стеке технологий я не нашел, можно предположить, что это какой-нибудь Spring Boot с дополнительным обвесом.


Hello World!


Самое простое приложение, написанное на Quarkus, будет выглядеть так:


@Path("/hello")
public class GreetingResource {

   @GET
   @Produces(MediaType.TEXT_PLAIN)
   public String hello() {
       return "hello";
   }
}

Это буквально один класс и его достаточно! Можно запустить приложение при помощи Maven в режиме разработки:


mvn compile quarkus:dev
…
$ curl http://localhost:8080/hello
hello

Отличие от привычного приложения — нет класса Application! Quarkus поддерживает hot reload, так что можно менять приложение, не перезапуская его, тем самым разработка становится ещё быстрее.


Что дальше? Можно добавить сервис в контроллер при помощи аннотации Inject. Код сервиса:


@ApplicationScoped
public class GreetingService {

   public String greeting(String name) {
       return "Hello " + name + "!";
   }
}

Контроллер:


@Path("/hello")
public class GreetingResource {

   @Inject
   GreetingService service;

   @GET
   @Produces(MediaType.TEXT_PLAIN)
   @Path("/{name}")
   public String greeting(@PathParam("name") String name) {
       return service.greeting(name);
   }
}

$ curl http://localhost:8080/hello/developer
Hello developer!

Заметьте, что в Quarkus используются стандартные аннотации из знакомых фреймворков — CDI и JAX-RS. Ничего нового учить не надо, если вы работали с CDI и JAX-RS до этого, конечно.


Работа с базой данных


Используется Hibernate и стандартные JPA аннотации для сущностей. Как и в случае с REST контроллерами, необходимо написать минимум кода. Достаточно указать зависимости в файле сборки, расставить аннотации @Entity и сконфигурировать datasource в application.properties.


Все. Никаких sessionFactory, persistence.xml и прочих сервисных файлов. Пишем только тот код, который нужен. Однако, при необходимости, можно создать файл persistence.xml и более тонко сконфигурировать ORM слой.


Quarkus поддерживает кэширование сущностей, коллекций для отношений один-ко-многим, а также запросов. На первый взгляд, выглядит здорово, но это локальное кэширование, для одного узла Kubernetes. Т.е. кэши разных узлов не синхронизированы между собой. Я надеюсь, это временно.


Асинхронное выполнение кода


Как было сказано выше, Quarkus поддерживает и реактивный стиль программирования. Код предыдущего приложения можно записать в другом виде.


@Path("/hello")
public class GreetingResource {

   @GET
   @Produces(MediaType.TEXT_PLAIN)
   @Path("/{name}")
   public CompletionStage<String> greeting(@PathParam("name") String name) {
       return CompletableFuture.supplyAsync(() -> {
           return "Hello " + name + "!";
       });
   }
}

Асинхронный код также можно перенести в сервис, результать будет таким же.


Тестирование


Тесты для Quarkus-приложений можно писать на JUnit4 или JUnit5. Ниже дан пример теста для endpoint, он написан при помощи RestAssured, но можно использовать и другой фреймворк:


@QuarkusTest
public class GreetingResourceTest {

   @Test
   public void testGreetingEndpoint() {
       String uuid = UUID.randomUUID().toString();
       given()
         .pathParam("name", uuid)
         .when().get("/hello/{name}")
         .then()
           .statusCode(200)
           .body(is("Hello " + uuid + "!"));
   }
}

Аннотация @QuarkusTest предписывает запустить приложение перед тем, как запускать тесты. В остальном — знакомый всем разработчикам код.


Платформо-зависимое приложение


Поскольку Quarkus тесно интегрирован с GraalVM, то, конечно же, можно генерировать платформо-зависимый код. Для этого нужно установить GraalVM и указать переменную среды GRAALVM_HOME. Дальше прописать профиль для сборки и указать его при сборке приложения:


mvn package -Pnative

Что интересно, сгенерированное приложение можно протестировать. И это важно, поскольку исполнение “родного” кода может отличаться от исполнения на JVM. Аннотация @SubstrateTest запускает платформо-зависимый код приложения. Переиспользование существующего кода тестов можно осуществить при помощи наследования, в итоге код для тестирования платформо-зависимого приложения будет выглядеть вот так:


@SubstrateTest
public class GreetingResourceIT extends GreetingResourceTest {

}

Сгенерированный образ можно запаковать в Docker и запускать в Kubernetes или OpenShift, подробно описано в инструкции.


Инструментарий


Фреймворк Quarkus можно использовать с Maven и Gradle. Maven поддерживается в полной мере, в отличие от Gradle. К сожалению, на текущий момент Gradle не поддерживает генерацию пустого проекта, на сайте есть подробный учебник.


Расширения


Quarkus — расширяемый фреймворк. На текущий момент существует порядка 40 расширейний, которые добавляют различную функциональность — от поддержки Spring DI контейнера и Apache Camel до логгирования и публикации метрик для работающих сервисов. И уже существует расширение для поддержки написания приложений на языке Kotlin, в дополнение к Java.


Заключение


По моему мнению, Quarkus вполне себе в трендах времени. Разработка backend кода становится все проще и проще, и этот фреймворк ещё больше упрощает и ускоряет разработку сервисов, добавляя “родную” поддержку Docker и Kubernetes. Огромный плюс — встроенная поддержка GraalVM и генерации платформо-зависимых образов, что позволяет делать сервисы по-настоящему быстро стартующими и занимающими мало места в памяти. А это очень важно в наше время массового увлечения микросервисами и serverless архитектурой.


Официальный сайт — quiarkus.io. Примеры проектов для быстрого старта уже есть на GitHub.

Комментарии (18)


  1. rraderio
    11.03.2019 13:21
    +1

    Чем он луше micronaut.io?


    1. a_belyaev Автор
      11.03.2019 15:08

      На мой взгляд — идеологически они сильно похожи. На micronaut я не писал сколько-нибудь масштабный и сложных проектов, поэтому мне сложно сейчас сложно рассуждать о плюсах и минусах этих фреймворков. Явное отличие — в Quarkus нет Application.java :-)


  1. mikhailian
    11.03.2019 13:51

    Dropwizard, SparkJava тоже были молодыми о многообещающими. Программисты брали поиграться и выбросить, чтобы потом самостоятельно набрать из низкоуровневых зависимостей то, что нужно для конкретного проекта.


    А кое-кто до сих пор плачет, колется, но до сих пор мучается с разбором путей в SparkJava или с зависимостями в Dropwizard.


    1. a_belyaev Автор
      11.03.2019 15:23

      Конечно, сложно предугадать, выстрелит фреймворк или нет. Много факторов: привычность/удобство использования, стабильность, поддержка, скорость развития, количество интеграций, сообщество. Посмотрим, что получится с Quarkus. Что меня привлекает — они полагаются на существующие фреймворки, просто убирают boilerplate. А так, если до этого вы использовали Hibernate/JAX-RS/CDI, то переезд на quarkus не должен занять много времени.


  1. iliabvf
    11.03.2019 13:56

    Собираетесь включить в Cuba Platform?


    1. a_belyaev Автор
      11.03.2019 15:11

      Пока нет. Слишком много неопределенности, чтобы этот фреймворк тащить в платформу.


  1. Throwable
    11.03.2019 17:47

    Что меня больше всего настораживает во всех этих катапульт-фреймфорках — это то, что потом любое изменение "не по плану" всегда оборачивается жуткой головной болью. И в что мы экономим? Лишних полчаса, чтобы собрать проект из явных зависимостей?


    1. a_belyaev Автор
      11.03.2019 18:51
      +1

      Spring Boot — это катапульт-фреймворк? Он тоже позволяет быстро клепать приложения для backend и не прописывать явные зависимости. Однако, в его случае, похоже, польза от применения перевешивает жуткость головной боли. Судя по всему, quarkus, да и micronaut идут по тому же пути, как spring boot. На мой взгляд, они довольно расширяемы, и, как мне кажется, в 90% случаев их стандартной функциональности достаточно для разработки разных видов приложений (у Quarkus, конечно, меньше всяких расширений сейчас). А экономим мы усилия по написанию всякого сервисного кода и сдруживанию разных зависимостей, которые не всегда можно быстро сдружить.


      1. mad_nazgul
        12.03.2019 07:08

        В отличии от других фреймворков, к Spring доверия больше. Т.к. он доказал, что гибкий и умеет приспосабливаться к современным трендам.
        Расплата же конечно, в его «тяжеловестности».


      1. Throwable
        12.03.2019 13:34

        Spring Boot — это самая настоящая катапульта. Она позволяет быстро написать приложение "Хелло ворлд" с кучей подключенных технологий, абсолютно не задумываясь о том, как это все работает. Реализация какой-то специфической задачи, не входящей в стандартный стек решений, уже не так тривиальна: требуется вдумчиво читать документацию, зазубривать конвеншны и @Заклинания, смотреть в кинотеатре сагу от Евгения Борисова и сильно уметь копаться в коде спринга. И все это в том случае, если программа более-менее написана грамотно.


        А экономим мы усилия по написанию всякого сервисного кода и сдруживанию разных зависимостей, которые не всегда можно быстро сдружить.

        Зачастую это кажущаяся экономия. Катапульты пытаются охватить сразу весь типовой стек решений (config + IoC + rest + database + integration + etc...). Однако интегрировать новую зависимость во фреймворк бывает на порядок сложнее, нежели в кастомном коде. А зачастую головную боль создают ограничения фреймворка, которые приходится грязно обходить. В особенности, когда не знаешь как оно внутри там вертится...


        1. mad_nazgul
          12.03.2019 15:02

          Как раз Spring framework по минимум мешает делать «свой велосипед».
          Из всех @Заклинаний, можно знать только @SpringBootApplication, @Configuration и Bean. А дальше можно писать свои «велосипеды» как хочешь.
          Не, ну можно выучить все @Заклинания, но это если нравиться «магия», когда произнеся «заклинание» делаешь пол проекта :-)


  1. maxzh83
    11.03.2019 21:38

    Странная статья. Я так понял, основная фича Quarkus — поддержка GraalVM, но на эту тему нет ни одного примера. Из того, что приведено, не вижу преимуществ по сравнению с тем же Spring Boot. Там сейчас есть все тоже самое: Spring Data, асинхронность, netty, docker, поддержка Котлина и т.д.


    1. mad_nazgul
      12.03.2019 07:08

      Так «легковестность» же :-)


      1. maxzh83
        12.03.2019 08:58

        Ага, hibernate прямо пушинка


        1. mad_nazgul
          12.03.2019 12:25

          Просто hibernate единственная «нормальная» имплементация JPA.


          1. maxzh83
            12.03.2019 14:52

            С этим не спорю, но запросы генерит часто тяжелые и много лишних.


            1. mad_nazgul
              12.03.2019 15:03

              Так «за все надо платить».


  1. lxsmkv
    12.03.2019 00:01

    Сайт случайно не на фреймворке сделан? А то там при нажатии на ссылку 5 секунд задержка до отображения.