Зачем нужны микрофреймворки?

Последние пару лет на конференциях часто обсуждают микрофреймворки и активно сравнивают их со Spring.

Joker 2019: Micronaut vs Spring Boot
Joker 2020: Spring: Your next Java microframework

Спикеры показывают, как легко на микрофреймворках создать сервис из 3х классов, и как мало памяти он потребляет. Как Spring Boot приложение стартует за одну секунду, если выкинуть из него всё полезное.

Экономия 50 МБ - это здорово, но не настолько, чтобы срочно менять фреймворк. В этом посте я расскажу, в каких случаях полезны микрофреймворки и что означает приставка "микро".

🌚 Перенесёмся на 10 лет назад

Компания ведёт деятельность в интернете. У неё несколько веб-сервисов, допустим на Spring. В компаниях есть "серверные" - большие комнаты с кучей оборудования. На них развёрнуты приложения, готовые к наплыву пользователей. Даже когда пользователей мало, сервера стоят в полной готовности. Экземпляр сервиса запущен неделями, а релиз - волнительное для всех событие.

🌝 Наши дни

Серверные освободились от железок и стали комнатами отдыха. Приложения запускаются на сторонних сервисах. Это удобно - можно быстро поднять и уничтожить любое количество экземпляров, а платить только за использованные ресурсы. Мало пользователей - мало сервисов. Нагрузка растёт - добавляем ещё.

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

Классическое приложение на Spring стартует больше минуты. Пока запускается, помощь уже может и не понадобиться.

Проблему долгого старта решают микрофреймворки.

Микро - потому что для микросервисов. Чёткой границы между сервисом и микросервисом нет, так же функционально нет чёткой границы между фреймворком и микрофреймворком. Это полноценные приложения, которые могут и запросы принять, и к БД обратиться, и провернуть сложную бизнес-логику.

Ключевое отличие - это быстрый старт сервиса🚀

Магия фреймворков скрыта за аннотациями. По ним фреймворк создаёт классы-обёртки, в которых спрятан скучный код. Прокси классы создаются во время компиляции (микрофреймворки) или во время запуска программы (Spring). Понятно, что если классы созданы заранее, то приложение стартует гораздо быстрее.

Подробно об аннотациях и Retention можно почитать в этом посте.

Аннотации микрофреймворков очень похожи на аннотации Spring. Например, o.s.w.b.a.RestController для Micronaut превращается в i.m.h.a.Controller(produces = [TEXT_JSON]). Микрофреймворки активно развиваются и легко интегрируются с популярными 3rd parties.

Но перейти с одного фреймворка на другой - это не шутка. Как минимум надо переписать все аннотации и терпеть долгую компиляцию. Некоторые проекты даже на java 11 не обновляются, а смена фреймворка тем более должна иметь серьёзное обоснование. Если ваш проект не дошёл до стадии, когда сервисы запускаются по необходимости, то можно остаться на старом добром Spring.