Какую архитектуру и фрейморк выбрать для реактивного приложения на джаве?

Question

[javax]

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

1. Важно ли при выборе фреймворка, что наше приложение полностью stateless? Т.е. нам не нужно следить за безопасностью доступа к состоянию сервисов, всё thread safe.
2. Если сервисы синхронные и я их вызываю асинхронно (как например executeBlocking в Vertx), хуже ли это для производительности (или еще для чего то), что асинхронные сервисы (использующие реактивные HTTP клиенты и JDBC драйверы)?
Есть ли в этом плане разница между Vertx и WebFlux?
Если разницы нет - то почему бы не писать синхронные сервисы (их так легче писать и тестировать) и вызывать их потом асинхронно из слоя контроллеров?
3. Мне больше нравится, когда во фреймворке слой контроллеров возвращает результат (как Mono/Flux в WebFlux или Future в akka-http), по сравнению с написанием onHandle() в Vertx.
Так, мне кажется, более читаемо и меньше кода. Я прав или я чего то не вижу?

Если я прав в 2 и 3 - какой фреймворк можете посоветовать?
Если не прав - почему? И опять же - какой фреймворк посоветуете?

Comments

[Dmitri Sinitsa]

Первое, что приходит на ум - Play Framework ( https://www.playframework.com/ )
Но он лучше дружит со Scala, а не с Java.

Получаем stateless web tier, обёрнутый во Future монаду для того, чтобы получить non-blocking IO, и всё это скармливается серверу Netty.
Для каких-то дополнительных реактивных примитивов есть Rx, RxScala в данном случае.
В сам фреймворк уже впилена Akka.

Answer 1

[⚡ Kotobotov ⚡]

1. Для реактивного подхода да важно.
У вас нет зависимого состояния в случае отдельного сбоя в отдельном узле, можете легко восстановить работу узла, без особых заморочек, это часть подхода.
2. Для производительности на отдельный запрос - асинхронные вызовы всегда хуже. Мы делаем запросы асинхронными не для того чтоб выжать максимум из одного запроса. Асинхронность открывает путь к параллелизации (раз нет зависимости, запросы могут быть выполнены в любом порядке, в том числе и параллельно), такие запросы повышают отзывчивость системы (интерфейса), лучше распределяют нагрузку.
3. Работа с коллбэками - всегда было то еще удовольствие, композиция функций конечно более предпочтительна.
----------
для создания реактивной архитектуры традиционно - akka, play, kafka (все это с джавой работает в том числе)

Comments

[javax]

Про 2. не понял, можете пояснить?
Чем отличается использование реактивного http клиента или драйвера БД от асинхронного вызова синхронного клиента или ДБ драйвера?

[⚡ Kotobotov ⚡]

javax, хех, такие у вас формулировки, что можно запутаться, то что клиент "синхронный" не имеет никакого значения, вопрос какой запрос у нас к нему, синхронный или ассинхронный.
По поводу реактивного подхода (под этим часто подразумевают разные вещи), но предположу что идет речь о таких клиентах которые имеют обратную связь и более богатый набор уведомлений, например клиент может сообщить тому кто делает запрос, готов ли принимать запрос, или вам нужно подождать с отправкой запроса (механизм back pressure) ну и больше разницы никакой.

[javax]

⚡Дима Кубитский ⚡, Понял, спасибо!

А с vertx или WebFlux Вы не знакомы?

[⚡ Kotobotov ⚡]

javax, не знаком