Java Word

• SPRING BOOT
• VERT.X

В большинстве приложений нет узкого места на стороне запроса. Делайте проще. Реально не шучу: лучший навык, который вы можете освоить, - это делать проще. Не пытайтесь решать проблемы, которых у вас нет.

Большинству приложений не нужна реактивность; в целом, можно просто оставить приложение на старом добром Spring MVC, а если нужно масштабироваться, используйте небольшие облачные инстансы и масштабируйтесь горизонтально.

Гораздо проще отлаживать, чем WebFlux, Vert.x или любую другую реактивную систему. Виртуальные потоки делают это еще проще.

Реактивность имеет свое место, но дополнительные затраты на обслуживание высоки, и их нужно оправдывать бенчмарками в каждом случае. Иначе это просто усложнение ради усложнения, что случается оооочень часто.

Я отвечаю за ~30 микросервисов, и у нас есть реактивные и legacy. Большинство проблем возникает из-за неправильно спроектированной архитектуры или плохих SQL/Mongo запросов, а не из-за реактивного или старого java стека.

Мне не нужно постоянно проводить бенчмарки, чтобы понять, что Reactive стек сэкономит много денег на серверах, увеличит пропускную способность или сможет обрабатывать всплески запросов в 10 раз без каких-либо проблем.

Важно помнить в реальном мире: час времени разработчика стоит дороже, чем дополнительные 20 Мб оперативной памяти. В некоторых фреймворках разработка идет быстрее, и в итоге это часто дешевле.

(Это тупо. Если у тебя 10 машин, ресурсы дешевые. Хочешь, жри лишние 10 ГБ оперативки и 2 ядра процессора. А что, если у тебя 100 машин, 1000 машин, 10000 машин... Железные затраты на неэффективность становятся огромными по сравнению со временем инженера.)