Реактивное программирование со Spring Boot 2. Часть 1

[alek_sys]

Спасибо за статью! Хотя я не очень понимаю целевую аудиторию — совсем новичкам в реактивном программировании она ничего не объяснит, а людям, знакомым с RxJava или Reactor ничего нового не даст.

Пара вещей, которые стоит отметить, говоря про реактивный Spring:

• Spring MVC не использован т.к. он построен на спецификации сервлетов, которые (пока) не особо реактивные
• Помимо WebFlux реактивный Spring включает еще и реактивный доступ к данным (Mongo, Redis), безопасность (Spring Reactive Security) — ведь если все контроллеры реактивные, но доступ к базе блокирующий — то смысла в реактивности особо нет

И важный момент насчет тестов — тестирование кода фреймворка или вообще любого внешнего кода это не всегда хорошая идея. Хотя в статье это иллюстрация работы Mono / Flux, но в целом тестировать функции just и map не нужно вне контекста вашего кода.

[faoxy]

Она для людей, которые работают со Spring Boot, но пока не видели Spring Boot 2.

[trix]

"// Блокируем текущий поток до тех пор пока не получим объект"

ничего, что это чуть ли не главная проблема, которую реактивный подход пытается решить? :) а вы прямо под этим примером гордо пишете «использовать реактивный подход довольно просто»

[faoxy]

Мне кажется, для первого примера неплохо. :)

[maxzh83]

Это все здорово, но к сожалению пока Spring Data не умеет работать асинхронно с JPA/jdbc. И это во многих случаях делает бессмысленными все дальнейшие реактивные манипуляции.

[vlanko]

Пока в первой статье непонятно, чем это лучше Stream

[zesetup]

Я правильно понимаю, что это для микросервисной архитектуры? То есть пока у нас была БД, как поставщик данных, то она редко была нетерпимо медленной, если же была, то выставлялся кэш в памяти. Теперь данные идут от микросервисов, которые могут быть довольно тормознутыми. Чтоб не городить потоки, делают более простой способ организации параллельной работы — асинхронный, он же реактивный.