Comments 12
тема интересная, но из приведенных примеров не видно отличие реактивного программирования от обычного (кроме оборачивания всех данных в Flux и Mono)
Согласен, но ведь за одну статью целую реактивную систему не построишь. Именно поэтому я и решил оставить такой P.S. Здесь я постарался сосредоточится на том как выглядит работа в таком режиме. Например, обратите внимание на действия в сервисном слое. Они отличаются от привычного декларативного стиля.
Есть небольшой вопрос касательно
И еще вопрос как работает такой reactive repository с DB кешем или пока всё напрямую тащим из базы?
getByLastName метода. Для 'Hello World' выглядит неплохо. Но такое же ведь нельзя использовать на очень больших объемах данных? На каждый чих (запрос) мы будем вгружать всех юзеров и только потом фильтровать как я понимаю, а это при миллионе записей думаю будет неплохой удар ниже пояса. И еще вопрос как работает такой reactive repository с DB кешем или пока всё напрямую тащим из базы?
Логику выборки данных из базы мы реализуем в сервисе только в качестве показательного примера. В продакшене, конечно, это надо делать через запрос на стороне базы. Здесь хотел показать как выглядит работа с бизнес логикой в слое сервиса, вот и все. Именно поэтому я написал: «Конечно, такую логику можно возложить на базу данных, но здесь я хотел бы обратить внимание как это будет выглядит в сервисе».
И второй вопрос. Кеш БД, на сколько я понимаю, остается и реализуется на уровне взаимодействия драйвера(обратите внимание, что здесь используется специальный драйвер) и базы.
И второй вопрос. Кеш БД, на сколько я понимаю, остается и реализуется на уровне взаимодействия драйвера(обратите внимание, что здесь используется специальный драйвер) и базы.
Ну вот было интересно проводилось ли вскрытие этого специального драйвера с целью понять кеш есть или нет?)
Сегодня еще вспомнил что хотел спросить, это возвращаясь к теме специального драйвера и репозитория.
Сможет ли webflux спокойно работать с методами декорированными
Получается что в теории можно намешать синхронку «под асинк соусом» и webflux. Ведь всё равно для некоторых баз нет async драйвера и иди знай когда появится. (И да я понимаю что в таком случае база будет боттлнеком, с её локами и прочим)
Сможет ли webflux спокойно работать с методами декорированными
@Async? Поддержка CompletableFuture и Stream в том-же spring-data есть. Mono класс я вообще как посмотрел — вылитый аналог CompletableFuture. Получается что в теории можно намешать синхронку «под асинк соусом» и webflux. Ведь всё равно для некоторых баз нет async драйвера и иди знай когда появится. (И да я понимаю что в таком случае база будет боттлнеком, с её локами и прочим)
UFO just landed and posted this here
Двоякая вещь, на самом деле. Пока базы данных не умеют работать в неблокирующей манере, и всё сводится к отдельному пулу потоков, в которых мы выполняем блокирующие операции (пускай это и скрыто от глаз разработчика в драйвер БД), реактивное программирование будет применимо далеко не везде.
Спасибо:) Жду продолжения. Небольшое замечание- в сервисе и контроллере мне кажется вместо get() более адекватно getAll(). Ну и картинки мне не очень..
А .findAll()
.filter
не тянет все из БД?
Вижу, что тянет. А что реактивного дает драйвер Монго?
.filter
не тянет все из БД?
Вижу, что тянет. А что реактивного дает драйвер Монго?
В статье явно присутствуют фактические ошибки. Оригинал туториала по работе с Reactive-репозиториями находится тут. В отличие от данного туториала там не предлагается делать findAll()/filter(), а необходимые методы поиска и фильтрации зашиваются в сам репозиторий. Отличие от нереактивного репозитория только в том, что мы можем работать с результатами в «реактивном стиле» через коллбэки и возвращать не сам результат, а поток (flux или mono).
где же третья часть?
Sign up to leave a comment.
Реактивное программирование со Spring Boot 2. Часть 2