Ненормальное реактивное программирование

[rolaman]

C WebFlux вложенности не избежать, хорошие примеры когда не стоит это юзать

[znvTramp]

Описанное в статье может показаться преувеличением, но в реальности все именно так и есть! У нас архитекторы приняли решение все делать реактивным как раз "чтобы быть готовыми к большим нагрузкам"… Разгребаем до сих пор.
P.S. Ещё один момент не освещенный в статье: если метод возвращает Mono — то просто протестировать, что к этому методу было обращение уже не достаточно. Так как если на этом методе никто не сделал subscribe (явно или "встраивая" его в реактивный pipeline) то вызван он по сути в итоге и не будет. Для таких случаев просто проверять обращение к методу с помощью mockito уже бесполезно и нужно дополнительно добавлять в тесты PublisherProbe (о чем мы, конечно же, не знали и огребли ещё кучу проблем, когда мигрировали старый код, полностью покрытий тестами).

[znvTramp]

"если метод возвращает Mono" — должно было быть "если метод возвращает Mono<Void>"

[ashofthedream]

У друзей сейчас та же самая история, давайте все писать реактивно, и так же, если метод делает какую-то бизнес логику, и даже не думает лезть во внешние сервисы, он должен быть реактивным. В результате чего куча проблем на ровном месте

[darkit]

Можно и витамином Ц объесться и помереть. Но это ведь не значит, что он вредный.
Реактивщина отлично заходит на IO bounded задачах. И чего мелочиться с примерами — можно завернуть все в к8с с истио и считать все в хадупе. Чтобы показать какой великолепный и понятный подход плодить на каждый веб запрос по реквесту :)

[ashofthedream]

Это правда, есть много разных способов себе навредить, но этот пост по сути вырос, как у комментатора выше, из доведение использования одной из технологий до абсурда, ну а ранним утром в понедельник мне действительно нечего было делать, и я решил немного поиграться с реактивной совсем в ином контексте

[darkit]

Надо было идти до конца и фигачить subscribeOn, publishOn и parallel :)))

[Hab_Reader]

Крайне трудно, потому что избыток витамина C — легко выводится с мочой, по той причине что предки человека жили на деревьях и регулярно объедаясь фруктами получали его избыток.

[trix]

Обещали сдержать себя от того, чтобы не использовать пару микросервисов, а сдержали от того, чтобы использовать. Кругом обман :(

[ashofthedream]

Больше нет доказательств вашим словам

[donbeave]

Хороший формат. Приятно читать, не скучно, я бы даже некоторые вещи растаскал на цитаты.

[chapuza]

Вы, и комментаторы выше, хором твердите про то, что мы бесплатно получаем back pressure. Я не очень понимаю, каким именно образом, если честно. Иными словами, что случится, если на восьмиядерной машине придет запрос инвертировать девять деревьев? Flux разрулит?

Спору нет, это все гораздо разумнее, чем синхронно долбиться в стену, но чтобы сдерживать back pressure нужен, как минимум, отдельный поток/процесс, просто от переписывания все в реактивненьком стиле чуда не произойдет.

Или я чего-то не понимаю? (Я просто джаву/шарп в последний раз нюхал лет 15 назад и подотстал, но мне действительно интересно).

[mayorovp]

Отдельный поток/процесс нужен не для того, чтобы сдерживать back pressure, а чтобы проблема back pressure вообще появилась. В однопоточном синхронном коде back pressure работает просто по построению.

[chapuza]

В однопоточном синхронном коде back pressure работает просто по построению.

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

[mayorovp]

Это зависит от того как передатчик написан. Да, он может не суметь обработать back pressure и из-за этого отвалиться, но сам back pressure от этого же никуда не девается.

[chapuza]

Передатчик обычно не наш, а если и наш — это вообще не его дело. «Я вот вам поставляю продукты бесперебойно, вы уж там сами как-нибудь со своим складом разберитесь.»

У нас очень много такого типа задач, и это всегда решается тем, что мы принимаем все, чтобы не возникало пробок вне нашего контроля, а потом разгребаем всеми доступными потоками. Иногда приходится даунскейлиться на менее тщательную обработку, и т. п. Просто «потоками» и «асинхронностью» bask pressure не решается чуть более, чем никак.

[mayorovp]

Ну вот в тот момент, когда вы решили принимать всё, у вас и появилась проблема baсk pressure: если не решить что с делать, то программа однажды просто свалится из-за исчерпания памяти.

Теперь да, её нужно как-то решать.

[chapuza]

Кхм. Это не мы решили, это бизнес решил.

Поэтому я и говорю, что реативненькое программирование проблему back pressure не решает.

[mayorovp]

Э-э-э, а где тут связь?

[chapuza]

В статье, в комментариях выше моего, в моем комментарии, начинающем этот тред.