Reactor, WebFlux, Kotlin Coroutines, или Асинхронность на простом примере

[dididididi]

5 селектов и всего один инсерт — мечта))) А обычно пять инсертов и один селект.

[nerumb]

В backend Kotlin уже полно. Даже с блокирующим JDBC иногда имеет смысл использовать корутины. Например, можно обернуть выполнение задачи на ThreadPool в методе, который возвращает CompletableFuture, а на нем уже можно использовать await из корутин, чтобы дождаться результата.
А в скором будущем будет R2DBC, который будет возвращать реактивные типы, и на которых также можно будет вызывать методы из корутин.

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

[tolkkv]

R2DBC уже есть :)

Можно брать и начинать пользоваться потихоньку. Релиз уровня webflux ранних версий. Кафка версии 0.8 людей не смущает, а R2DBC смущает

[nerumb]

Еще хотелось бы R2DBC под все популярные БД, в том числе для Oracle =)

[tolkkv]

под популярные уже есть (см тут – habr.com/ru/company/jugru/blog/478384)
Под Oracle конечно же пока нет :)

Помимо поддержки БД уже есть и библиотека для пула github.com/r2dbc/r2dbc-pool
и даже прокси github.com/r2dbc/r2dbc-proxy

[zacisco]

лично мне очень hikari нравится, очень быстрый и оптимизированный пул в сравнении с другими… вот туда бы завезли r2dbc и был бы шик

[nerumb]

А вот то что меня постоянно раздражает в самом котлине:..

Для этого есть причина. Для inline врапперов можно делать нелокальный возврат из функции.

[tolkkv]

А зачем в примере с webflux у тебя ещё и publishOn? ;)

val cacheRequest = serviceRequest.cache()
       .publishOn(Schedulers.parallel())

[nerumb]

Да, тут лишнее =)
Спасибо, подправил.

[tolkkv]

:+1:

[cas_pername]

Не нашел в статье ничего про сам процесс создания coroutineScope, можно про это поподробнее? Спасибо за статью!

[cas_pername]

У меня не подгрузился импорт, извините
)

[shishmakov]

nerumb вы не уточнили затрченное время на исполнение запросов в последних примерах.

• Spring MVC ~ 700мс,
• Spring MVC + CompletableFuture ~ 360мс,
• Spring WebFlux ~? мс,
• Spring WebFlux + Coroutines ~? мс

Исходя из логики повествования она будет так же примерно равна 360мс так как вы делаете акцент на пропускной способности:

наш сервис только лишь рассылает запросы в другие сервисы. Выделять под это целый поток и блокировать его, пока не придут ответы от всех, выглядит, мягко говоря, излишним.

[nerumb]

Все верно, там аналогично будет в районе 360мс для всех остальных реализаций.