Quarkus — сверхзвуковая субатомная Java. Краткий обзор фреймворка


    Введение


    Седьмого марта компания 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 архитектурой.


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

    Haulmont
    158,00
    Создаем современные корпоративные системы
    Поделиться публикацией

    Похожие публикации

    Комментарии 23

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

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


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

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

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

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

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


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

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

                    0
                    Как раз Spring framework по минимум мешает делать «свой велосипед».
                    Из всех @Заклинаний, можно знать только @SpringBootApplication, @Configuration и Bean. А дальше можно писать свои «велосипеды» как хочешь.
                    Не, ну можно выучить все @Заклинания, но это если нравиться «магия», когда произнеся «заклинание» делаешь пол проекта :-)
                +1
                Странная статья. Я так понял, основная фича Quarkus — поддержка GraalVM, но на эту тему нет ни одного примера. Из того, что приведено, не вижу преимуществ по сравнению с тем же Spring Boot. Там сейчас есть все тоже самое: Spring Data, асинхронность, netty, docker, поддержка Котлина и т.д.
                  0
                  Так «легковестность» же :-)
                    0
                    Ага, hibernate прямо пушинка
                      –1
                      Просто hibernate единственная «нормальная» имплементация JPA.
                        0
                        С этим не спорю, но запросы генерит часто тяжелые и много лишних.
                          0
                          Так «за все надо платить».
                  0
                  Сайт случайно не на фреймворке сделан? А то там при нажатии на ссылку 5 секунд задержка до отображения.
                    0
                    Зачем он нужен?
                    Пользуюсь чистым Vert.x, никаких проблем не испытываю.
                      0
                      Значит, Vert.x отлично ложится на привычные абстракции, который есть у вас в голове :-) Но есть же люди, которые думают не совсем так, как вы, а как разработчики Quarkus. И им, может быть, невыносимо неудобно пользоваться vert.x, а quarkus зайдет отлично :-)

                      Кому-то нравится писать hello world так:
                      public class Server extends AbstractVerticle {
                        public void start() {
                          vertx.createHttpServer().requestHandler(req -> {
                            req.response()
                              .putHeader("content-type", "text/plain")
                              .end("Hello from Vert.x!");
                          }).listen(8080);
                        }
                      

                      а кому-то — так:
                      @Path("/hello")
                      public class GreetingResource {
                      
                         @GET
                         @Produces(MediaType.TEXT_PLAIN)
                         public String hello() {
                             return "hello from quarkus";
                         }
                      }
                      

                        0
                        Вопрос даже не в этом.
                        Понятно, что Springовый подход к разработке сильно проник в головы.
                        Непонятно, зачем тянуть 100500 тяжеленных зависимостей, чтобы отображать в браузере текст?
                          0
                          100500 тяжеленных зависимостей
                          обычно тянут не чтобы показать 2 строчи текста в браузере, а чтобы 100ГБ исходных данных превратить в 2 строчки осмысленного текста.
                            0
                            Об этом в статье ни слова, к сожалению.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое