Comments 7
Спасибо за статью! Хотя я не очень понимаю целевую аудиторию — совсем новичкам в реактивном программировании она ничего не объяснит, а людям, знакомым с RxJava или Reactor ничего нового не даст.
Пара вещей, которые стоит отметить, говоря про реактивный Spring:
- Spring MVC не использован т.к. он построен на спецификации сервлетов, которые (пока) не особо реактивные
- Помимо WebFlux реактивный Spring включает еще и реактивный доступ к данным (Mongo, Redis), безопасность (Spring Reactive Security) — ведь если все контроллеры реактивные, но доступ к базе блокирующий — то смысла в реактивности особо нет
И важный момент насчет тестов — тестирование кода фреймворка или вообще любого внешнего кода это не всегда хорошая идея. Хотя в статье это иллюстрация работы Mono / Flux, но в целом тестировать функции just и map не нужно вне контекста вашего кода.
ничего, что это чуть ли не главная проблема, которую реактивный подход пытается решить? :) а вы прямо под этим примером гордо пишете «использовать реактивный подход довольно просто»
Я правильно понимаю, что это для микросервисной архитектуры? То есть пока у нас была БД, как поставщик данных, то она редко была нетерпимо медленной, если же была, то выставлялся кэш в памяти. Теперь данные идут от микросервисов, которые могут быть довольно тормознутыми. Чтоб не городить потоки, делают более простой способ организации параллельной работы — асинхронный, он же реактивный.
Реактивное программирование со Spring Boot 2. Часть 1