hello world на полном серьезе уже странно звучит)

Да, но эти бенчмарки ровно об этом 😄

да, но RSocket это немного другое. нет? это какойто аналог gRPC. протокол общения. и есть какието реализации под разные платформы/языки. поправьте если не прав

тем не менее это говорит о количестве оверхеда

Ну да, но это не новость, да и код зато красивый
https://github.com/TechEmpower/FrameworkBenchmarks/blob/4005e69bff475bf953099292bc8fc796555e633c/frameworks/Java/spring/src/main/java/hello/controller/HelloController.java#L35

micronaut при схожей функциональности раза в 2 выше находится

да, это что-то типо gRPC. Вот gRPC же генерирует уже определенные методы, их сигнатуру то есть. А тут у фреймворка просто есть требование (хм, я не уверен, можно ли сделать сигнатуру без Mono/Flux) - на реаткивное API.

В любом случае, rsocket построен на netty. Писать блокирующий код не выйдет, ну, или придется использовать созданные руками пулы потоков

а голый undertow на 19-м месте

netty только за обработку запросов извне отвечает. и никак не обязывает использовать реактивное программирование
тот же спринг проект могу спокойно делать по умолчанию на embedded tomcat. а потом просто в pom.xml поменял зависимость - и у тебя уже netty.
настройки для tomcat и netty конечно разные. но по коду ничего менять не нужно в принципе...

т.е. если обходился раньше без Mono/Flux, то переход на netty не повлияет

1. хм, я немного не понимаю, про "просто в pom.xml поменял зависимость - и у тебя уже netty". Мы сейчас про какой фреймворк говорим? Спринг бут так не умеет, он чётко разделяет веб серваера для реактивного программирования и сервлетов.
2. я мог обходится без Mono/Flux, когда жил на Томкате, который использовал модель Поток-на запрос (в базовом случае). Но когда я перешел на нетти, который уже живет в евент лупе, мне нужна какая-то другая модель программирования, например, использованее Reactor Netty.

Все привет

кто тут про RSocket узнавал?

Anyways

> Rsocket  - он в первую степень для сервер-сервер взаимодействия, или клиент-сервер?

Для обох кейсов
может использоваться также хорошо как для так называемого edge-networ
состоящего из разного набора девайсов общающегося с твоим сервером
так и для сервер сервер
так как сам протокол являеться peer-to-peer
потому сервера могут свободно общаться по созданому соеденению друг с другом
+
это может быть ingress
представь кейс
что нужно опросить девайсы
или проадейтить что то
но клиент об этом не в курсе
типа мобилка или браузер
и вместо того что бы пулить сообщение (к примеру)
сервер может сам пушать данные
или например запрашивать данные
типа (а какой заряд телефона сейчас и тд)
понятное дело клиент может слать эту инфу с интервалом - но что если эта инфа нужно иногда
и не всегда
типа разовая акция
в таком случае клиентский код может обьявить API для хендлинга и сервер может запрашивать данные самостоятельно
Бенефит - клиент не может открыть серверный порт а при этом может вести себя как сервер (вот он peer-to-peer)

@OlehDokuka когда я пишу бэкенд на rsocket, я же должен его писать в реактивном стиле? То есть, Mono/Flux API. Или есть какое-то решение, если я хочу писать в блокирующем стиле свои API (если идет речь про request/response модель)

Ну, это в процесе доработки. На самом деле можно обойтись и без реактивщины; Никто не запрещает тебе сделать что то на подобии

это все можно отлично задекорировать

Mono<Payload> requestReponse(Payload p) {
   // do my blocking stuff here
   return Mono.just(responsePayload);
}

но в этом случае мы заблокируем все netty-потоки, и серверу придет конец?