Я экспериментировал с реактивным веб-фреймворком и у меня есть определенный вопрос, как он будет работать.
В типичном приложении у нас есть хранилище данных (реляционное или без SQL). Уровень приложения (контроллеры) для подключения для хранения и получения данных. Клиентский уровень (вызывает ваши конечные точки API) и получить данные.
Насколько мне известно, поставщики не опубликовали никаких асинхронных или реактивных драйверов (только у Mongo и, возможно, у Cassandra есть реактивные драйверы). Уровень контроллера будет передавать данные с помощью Mono, Flux или Single.
Клиентский уровень будет использовать эти данные.
Поскольку HTTP является синхронным по своей природе, как клиентский уровень или приложение выиграют от реактивной поддержки в Spring.
Вопрос: Допустим, у меня есть 10 записей в формате JSON, полученных из моего ответа Flux. Означает ли это, что мой клиент получит данные в потоке или весь набор данных будет сначала получен на стороне клиента, а затем процесс его использования будет реактивным по своей природе . В настоящее время у нас есть InputStream как ответ на вызов службы, который по своей природе является блокирующим из-за конструкции протокола HTTP.
Вопрос: Имеет ли тогда смысл иметь реактивную архитектуру для типичного веб-приложения, когда очень среда, на которую мы собираемся получить ответ, - это Blocking in Nature.
Spring Web Reactive использует неблокирующий ввод-вывод Servlet 3.1 и работает в контейнерах Servlet 3.1. Он также работает в средах выполнения, отличных от сервлетов, таких как Netty и Undertow. Каждая среда выполнения адаптирована к набору общих реактивных абстракций ServerHttpRequest и ServerHttpResponse, которые представляют тело запроса и ответа как Flux с полной поддержкой обратного давления на стороне чтения и записи.
