Комментарии 3
Прочитал, спасибо!
Главный вопрос — стоит ли ввязываться в это и побеждать подводные камни, или через N условных лет библиотеки намного лучше будут приспособлены к наличию реактивности в проекте? Речь не про изучение нового ради опыта, а практически — выиграл ли ваш проект?
Мы на нашем проекте рассматриваем такой путь: перед текущим сервлетным монолитом ставим spring cloud api gateway, затем по очереди вырезаем функциональные домены в отдельные микросервисы, попутно решая, кому их них быть реактивным, а кому опять сервлетным. Для внешних систем останемся тем же чёрным ящиком.
через N условных лет библиотеки намного лучше будут приспособлены к наличию реактивности в проекте?
С одной стороны, можно с уверенностью, что библиотеки совершенно точно будут (и уже давно начали) поддерживать реактивный подход: тот же Spring в каком-то смысле задал этот тренд, адаптировав свои фреймворки WebMVC (в виде WebFlux), Security и частично Integration; другие тоже на подхвате, например, feign-reactive и различные поставщики драйверов к БД. С другой стороны, их усилия, как правило, не нацелены именно на "скрещивание" сервлетного (а в более общем случае - императивного) подхода с реактивным; вместо этого они предлагаю самостоятельную реактивную альтернативу своим же собственным разработкам. Поэтому именно ждать N условных лет не стоит.
Однако это не значит, что ответ на вопрос:
стоит ли ввязываться в это и побеждать подводные камни
звучит как однозначное "да", потому что этот ответ сильно зависит от того, можете ли вы позволить себе не ввязываться и не побеждать, т.е. насколько сильно ваш проект/продукт связан с сервлетным стеком. В моём случе это проникновение было очень сильным, поэтому и пришлось идти таким тернистым путём. Этот путь был пройден совсем недавно, я вижу и верю в его позитивные результаты, но объявлять их окончательными пока не тороплюсь, нужно пожить с этим подольше (это ответ на вопрос "выиграл ли ваш проект?").
Что касается более общего случая, то ваш подход с выделением микросервисов на различных стеках кажется вполне удачным; мне известен ещё один такой пример продукта, и он весьма успешен. Конечно, за такой подход приходится платить двойственностью решений одних и тех же задач (то же логирование, например). Это большой минус. Но если в команде есть понимание и объективные оценки профита, то этот минус может быть полностью оправдан.
Спасибо за то, что поделились своим опытом. Все 3 статьи очень полезны, по крайней мере для меня
Уж+ёж: реактивные компоненты в сервлетном окружении (3/3)