Антон Котов - Reactive для CRUD: фантазии и реальность

Рет қаралды 3,581

2 ай бұрын

Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
Казалось бы, что может быть проще самого простого CRUD-сервиса, тем более на Spring? Тем не менее многообразие технологий и подходов для решения самых базовых проблем не дает нам однозначного ответа, когда ту или иную технологию лучше использовать.
В последнее время набирают популярность реактивные технологии, такие как WebFlux, в том числе на уровне взаимодействия с реляционными базами данных R2DBC. Появился и новый подход Project Loom.
Спикер разбирает, когда стоит использовать тот или иной подход, и подкрепляет выводы результатами нагрузочного тестирования.
Скачать презентацию с сайта Joker - jrg.su/ewxkPL
#crud #spring

Пікірлер: 21

@RickDkkrd 2 ай бұрын

Доклад начинается с 6:05

@usalkaz Ай бұрын

Как может быть бедный Hikari при R2DBC, если там используется специальный реактивный пул? То есть автор указал причину бессмысленности реактивного стека из-за HikariCP, хотя сам и не использовал реактивный пул. К тому же данный пул уже автоматически идет со стартером spring-data-reactive

@user-hr2dk6jy1k 2 ай бұрын

я что-то не услышал главного в этом докоаде, а зачем реактивный подход в crud функциях? микроскопом тоже гвозди забивать не удобно, значит ли, что микроскоп как инструмент не оправдал ожиданий?

@kotoant 2 ай бұрын

Комментарий от автора доклада: просто в последнее время все ударились в реактивщину, в том числе тащат ее для работы с реляционными базами данных, я же показал, что в большинстве случаев в этом как раз нет смысла. Я оставил свой развернутый комментарий к этому видео.

@user-hr2dk6jy1k 2 ай бұрын

@@kotoant спасибо за ответ. поясню что я услышал в докладе "перечисленные варианты использования реактивного подхода с crud функционалом не состоятельны, следовательно вам не нужен реактивный подход в 99%". я считаю что это не корректный посыл. нет смысла перебирать разные варианты реализации реактивного подхода в случае с crud. потому что в функции crud нет тех проблем, которые решаются реактивным подходом. то есть вся ценность этих сравнений производительности разных реализации сводится к нулю просто потому что рассматриваемая функция в принципе своём не должна решаться реактивно. но при этом реактивный подход может помочь в 95% функции всего проекта, если эти функции НЕ crud.

@TheLuChing 2 ай бұрын

Очень хороший доклад. Действительно, развенчивает миф о асинхронщине.

@Das.Kleine.Krokodil 2 ай бұрын

Интересно

@alexanderk3762 2 ай бұрын

Доклад - хорош.

@alexandersmirnov4274 2 ай бұрын

не понятно почему loom так обладжался там же подкапотом используется forkjoin pool а он берет количество потоков из количества процессоров кот у вас было 4 следовало бы увеличить его размер явно

@pawsdev 2 ай бұрын

Дак в итоге где выигрыш от реактивщины будет, если не в CRUD то где? Получается чисто в модулях сетевой логики, роутинга и расчётов типа ETL? НО ETL это тоже EXTARCT и LOAD.... НУ ок выделим TRANSFORM в отдельный Async модуль - ну хрень какая-то....

@user-qt8lo2qw8j 2 ай бұрын

Ну да, смысл Project Loom больше в запросах по сети, где нет ограниченных пулов коннекта, которые будут блокировать все потоки

@xz8928 2 ай бұрын

а где вообще есть неограниченные пулы коннекта ?

@user-qt8lo2qw8j 2 ай бұрын

@@xz8928 правильное замечание, на него ответ "нигде" :) Я хотел сказать, что виртуальные потоки не создают своих ограниченных пулов, но работают поверх обычных пулов потоков, емнип. Тот же ForkJoin по дефолту. То есть JVM эффективно управляет этими виртуальными потоками и для запросов по сети они будут большую часть времени спать, когда при запросах в базу будут блокироваться на чтение/запись и быстро выжирать предоставленный пул коннекта к базе. Наверно можно сказать так: пулы будут везде, просто виртуальные потоки получат преимущество там, где нет блокировок

@user-qt8lo2qw8j 2 ай бұрын

@@xz8928 нигде нет) Наверно стоило сказать что Project Loom юзается там, где потоки могут ожидать (сетевые запросы), поэтому от размера пула нет сильной зависимости. Но работают виртуальные потоки все равно поверх пулов и в коннектах к базе, например, пул будет забиваться блокирующими операциями в потоках.

@user-qt8lo2qw8j 2 ай бұрын