Пробуем Micronaut вместе с GraalVM Native Image

Всем привет. Сегодня я в первый раз поразрабатывал hello world на связке технологий — новом, мололежном фреймворке Micronaut и виртуальной машине Substrate.

Про Micronaut и Quarkus говорят все вокруг. Конечно, на работе мы всё еще пишем на Spring Boot, но, кто знает — может быть, спустя пару лет, у нас будет новый фрейиворк по умолчанию. В связи с этим, я решим поиграться с Micronaut.

Для знакомства с этой технологией я рекомендую вам прочитать замечательное интервью с Грэмом Роше от ребят из JugRU — https://habr.com/ru/company/jugru/blog/504944/.

Наверное, многих из вас мучает вопрос — что выбрать между Микронавтом и Кваркусом. Я могу попробовать дать краткое описание каждого из фреймворков.

Quarkus — это фреймворк, который построен поверх Eclipse Vert.x стека, но с более удобным API. В Quarkus есть хорошая поддержка реактивности (за счет Vert.x), довольно приятное API. В целом, это ваш выбор, если вы раньше делали что-то на Vert.x.

Micronaut — это, как будто Spring, сделанный в 2020 году. Тут вы найдете привычные для себя вещи, если писали на Српинге. Но, главные отличия — это dependency injection, сделанное во время компиляции. Лозунг Micronaut — скажи НЕТ рефлекшену. Именно благодаря такой реализации DI, Micronaut замечательно дружит не только с java частью GraalVM (с ней дружит и Quarkus), но и с Native Images.

Краткая справка для тех, кто забыл, что такое нативные образы в Граале, или Substrate VM. Если говорить кратко, это способ сделать ahead-of-time (AOT) компиляцию java-проекта. То есть, вы пишите привычный вам код на Kotlin или Java, а на выходе получаете бинарник, который уже запускается без необходимости в JVM (Substrate как раз таки реализует рантайм, нужный приложению — именно сюда и входит сборщик мусора).

Собственно, я сегодня почти повторил опыт из этой статьи — https://medium.com/tech-hunters/developing-production-ready-serverless-applications-with-kotlin-micronaut-and-graalvm-fff72d5c804b. То есть, взял Micronaut, написал какой-то приметивный код и собрал с помощью идущего в комплекте Dockerfile — образ, включающий в себя бинарник приложения.

Как ощущения от разработки? В целом, всё привычно, при условии, что есть Spring опыт. Что пока расстраивает — это две вещи:

  • Долгая компиляция практически пустого проекта. Это занимает порядка 5 минут, но, к счастью, вы можете при разработке использовать запуск приложения в JVM моде.
  • Очень большой бинарник. Пустое приложение у меня заняло 60345272 byte (57.5 MB). Есть, куда оптимизировать, как говориться.

В общем, мы живем в интересное время. Тут и джава AOT-иться, и потенциальные убийцы спринга появились. Остается только ждать и смотреть, что из этого выйдет.

Категории: Программирование