@Kirill_Amber

Зачем нужен WebFlux?

Можете ли привести проекты(или кейсы), при которых лучше всего подходит WebFlux? Пока не вижу кейсов, при которых не хватало SpringBoot, либо MicroProfile-фреймворков.
  • Вопрос задан
  • 100 просмотров
Пригласить эксперта
Ответы на вопрос 5
@mayton2019
Bigdata Engineer
Мне кажется что внедрение WebFlux идет от "реактивного манифеста". Вообще классические сервлетные серваки которые раньше поддерживались Tomcat/Jetty сегодня могут быть прозрачно подменены на netty, на уровне конфигураций бута, что как-бы приближает нас к асинхронщине. И современному бизнес-разработчику практически будет безразлично, написан ли его контроллер на блокирующем IO или на каком-то другом. По сути речь идет о диспетчеризации ресурсов. Где создавать поток. А где и хватит единого потока диспетчера на всех.

По поводу WebFlux, я видел один проект по обработке web-messages и это было удобно. Но только если мы на уровне алгоритма гарантируем что хендлер месседжа не будет занимать много времени.
Ответ написан
Комментировать
azerphoenix
@azerphoenix Куратор тега Java
Java Software Engineer
Чем хорош вебфлакс... асинхронностью.
По своему опыту скажу, что он имеет преимущества в плане отзывчивости перед вебом.

Пока не вижу кейсов, при которых не хватало SpringBoot, либо MicroProfile-фреймворков.

Уж поверьте, когда понадобится, тогда увидите нужные кейсы.

Мне например, приходилось разрабатывать приложение, который на вход принимает огромное количество точек (более 1000), строит маршруты и возвращает инструкции. Тав вот, асинхронно (flux) я возвращал данные по мере готовности. А если вы работаете с БД, то можете вместо jdbc подключить r2dbc.
Ответ написан
Комментировать
Jacen11
@Jacen11
не знаю как сейчас, а пару лет назад создатели спринга в своей доке говорили что если у вас уже все работает вам флакс не нужен, никаких преимуществ он не дает. Сделали потому что реактивный подход модный молодежный. Дело вкуса, кому что больше нравится
Ответ написан
Комментировать
xez
@xez Куратор тега Java
Senior Junior Roo
Я эту тему представляю так: вот есть стримы, которые позволяют писать понятно, в декларативном стиле, почти на человеческом языке, но с «одним недостатком» - они оперируют с уже какими-то уже «сложившимися» коллекциями.
Flux-ы предлагают похожий api, с которым можно сконструировать весь пайплайн приложения от начала до конца: от данных на входе, до данных на выходе, в таком же стиле.
Так что:
1. Это удобно
2. Сравнение со springboot - это тёплое против мягкого.
3. Flux-ы, применимы решительно в любом проекте, как развитие идеи стримов.
4. Идеально подходит, если речь идёт о mq или websocket.
Ответ написан
Комментировать
@Wan-Derer
По-моему, хороший ответ даёт вот этот мущщина :)
Если кратко, использование асинхронного подхода даёт более отзывчивое приложение. При этом оно может и не быть быстрее, но т.к. пользователь начинает быстрее получать первые данные, ему кажется что оно быстрее.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы