Спасибо за статью! Все выглядит очень здорово, когда вы работаете с какой-нибудь Монгой, где драйвер неблокирующий либо у вас несколько источников данных, дергающих другие сервисы. Максим Гореликов на прошлом Joker-e очень хорошо показал, как этой штукой пользоваться.

Спасибо, продолжение будет интересно.


numbersFromFiveToSeven = Flux.range(5, 3) поправить на (5,7) :)

Еще заметил, что с Reactor реализацией 5 мемов проверка на empty происходит не до, а после обращения к memeService. Издержки реализации или можно сделать логику идентично?

Это из-за особенности устройства Flux (и работы оператора flatMap()). Flux.empty() будет передан дальше по цепочке вызовов, а потом подхватится оператором switchIfEmpty(). Вместо тысячи слов:


Flux<String> emptyFlux = Flux.empty();
String lastValue = emptyFlux
        .flatMap((Function<String, Publisher<String>>) someValue -> {
            System.out.println("flatMap call");
            return Flux.just(someValue + "(is modified)");
        })
        .<String>switchIfEmpty(Flux.just(":("))
        .blockLast();
System.out.println("lastValue = " + lastValue);

Выведет грустный смайлик

По поводу Flux.range. Там нет ошибки, просто так устроен оператор:


/**
* @param start the first integer to be emit
* @param count the total number of incrementing values to emit, including the first value
* @return a ranged {@link Flux}
*/
public static Flux<Integer> range(int start, int count) {}

Он выводит значения начиная со start и по count-1.

Маленький шаг для человека, огромный шаг для spring.


Сложность с rx -стилем в коде только в том, что без контроля очень легко получить "мама-смотри-какой-я-умный" лапшу в коде, причем даже на небольшом количестве строк.


И с этой точки зрения корутины котлина с синтаксическим сахаром кажутся весьма хорошим решением вместе с project reactor и spring

Выглядит, как «ещё один rx». Имеются ли преимущества перед RxJava?

Перед RxJava 1? Очевидно есть. Перед RxJava 2? Отсутствие поддержки Java 6 + Android 2.3 + наследия RxJava 1, в связи с чем более "чистая" семантика. Лучшая поддержка фишек Java 8. Spring Boot 2, по умолчанию, предлагает использовать Reactor для реактивности, хотя это же Spring, поэтому можно подключить альтернативное решение.


Еще есть вот такой забавный твит, от "project lead of RxJava".

Отличная статья. "Повергается упоминанию" — замечательное выражение)


Вывод "Реактивность не делает ваш код производительнее, однако улучшает масштабируемость." вроде бы не следует из самой статьи, однако он следует из этой замечательной статьи: https://medium.com/netflix-techblog/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c было бы неплохо добавить на нее ссылку с комментарием, где-то ближе к началу статьи.

Да, отличная статья. Прикрепил ссылку, правда, к выводу.
RxJava и Reactor отличные штуки, но вот как только натыкаешься на JDBC и транзакцию, которая на несколько операций, то приехали :(

Да, в плане работы с JDBC — все очень плохо.


Но в случае чего, для работы с блокирующим источником, документация предлагает следующую конструкцию:


Mono blockingWrapper = Mono.fromCallable(() -> { 
    return /* make a remote synchronous call */ 
});
blockingWrapper = blockingWrapper.subscribeOn(Schedulers.elastic());

У нас в одном из сервисов есть вот такой метод:


public Mono<Boolean> createUserRelation(UserId objectId, UserId subjectId) {
    return Mono.fromSupplier(() -> {
        try {
            relationRepo.create(new UserRelationResource(objectId, subjectId));
            return true;
        } catch (Exception e) {
            logger.error(e.getMessage(), e);
            return false;
        }
    }).publishOn(elastic);
}

Оба варианта: publishOn() и subscribeOn() позволяют изменять поток выполнения. В случае с Schedulers.elastic(), можно сказать что он похож на стандартный ExecutorService newCachedThreadPool().

Проблема в том, что одно дело когда один блокирующий метод, а другое их несколько и они вызываются как угодно в зависимости от логики и надо иметь одну общую транзакцию :(

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

Спасибо за отличную статью – читается легко и на одном дыхании. Простое и незанудное изложение большой и сложной темы.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.