Все началось с рабочей задачи по реализации весьма специфичной web-панели мониторинга и управления различным оборудованием, в которой нужно было получать данные и отправлять команды по разнообразным сценариям (периодический опрос, подписка на websocket-события, https-запросы и т.д.), а также выводить состояние и графики в реальном времени, динамически комбинируя различные источники данных в разных виджетах.

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

В первой итерации с использованием RxJS получилось много неструктурированного и сложно поддерживаемого кода, так как архитектура на RxJS вынуждала императивно описывать перестроение топологии при изменении правил маршрутизации «на лету». В нашем специфичном кейсе с динамическими виджетами это приводило к сайд-эффектам и сложностям в отладке. Кроме того, местами размывалась строгая типизация и мы лишались compile-time гарантий. Так появилась идея разработать собственное решение на основе альтернативной концепции — модели графа потоков данных.

В результате получившаяся модель продемонстрировала предсказуемое поведение и низкую связность компонентов, а кодовая база сократилась на ~30% и приобрела более декларативный вид. Убедившись в эффективности решения, мы решили оформить его в виде отдельной библиотеки с открытым исходным кодом — Transferum.

И что, получилась просто еще одна реактивная библиотека?

Не совсем. Классические FRP-библиотеки (RxJS, Bacon, Most) построены вокруг единственного примитива (Observable). Transferum же основан на композиции различных типов узлов с явно определенным поведением.

Каждый узел в графе потоков распространения данных явно декларирует свои способности: может ли он принимать данные через push, отдавать через pull, распространять полученный сигнал подписчикам, опрашивать источник, фильтровать, блокировать поток и т.д.

Объявленные узлом возможности являются одновременно флагами для использования в runtime и compile-time гарантиями наличия соответствующих методов, определяющих его поведение.

Ключевая идея: поведение системы описывается как композиция независимых возможностей, которые одновременно определяют тип, реализацию и правила взаимодействия.

Transferum предоставляет четыре слоя абстракции:

1. Трансферы — узлы графа (каналы, поллеры, мапперы, буферы, разветвители и концентраторы, реализации debounce, throttle, switchMap и т.д.).
2. Мосты — ребра графа — управляемые вентили между узлами с динамической маршрутизацией и гейтингом.
3. Операторы — stateless-трансформаторы и фильтры данных (используются трансферами, отвечающими за конвертацию данных).
4. Билдеры — fluent-конструкторы композитных трансферов из цепочек трансферов-примитивов.

Концептуальная и архитектурная основа — capability flags system. Каждый трансфер реализует CommunicationContractInterface — набор булевых флагов, определяющих его возможности.

Флаги isPushable, isPullable, isSubscribable, isGate и другие — это не просто свойства объекта. Это метаданные, которые:

• Определяют TypeScript-интерфейс трансфера на этапе компиляции.
• Управляют стратегией связывания с другими трансферами в рантайме (с помощью функции linkTransfers()).
• Обеспечивают совместимость в билдерах без приведений типов.

Один набор флагов — три потребителя. Это единый источник истины для всей системы.

Когда флаг равен true, соответствующий метод входит в TypeScript-интерфейс трансфера. Это позволяет предоставлять трансфер пользователю вот так:

Или вот так:

Именно в таком формате типов фабрики в библиотеке возвращают трансферы. Например:

Эта «магия» работает в compile-time благодаря несколько замысловатой системе вычислимых типов:

Архитектурные инварианты

1. Трансферы не знают своих соседей

Трансфер определяет своё поведение (push, pull, subscribe и др.), но никогда не ссылается и не проверяет класс другого трансфера. Он не знает, что является upstream или downstream — лишь выполняет свой контракт. Пользователь может создать свой трансфер, объявить и реализовать его возможности — и он органично и бесшовно впишется в экосистему.

2. Мосты не знают конкретных реализаций

Мост инспектирует capability flags, а не имена классов. Нет цепочки instanceof, нет переключения по имени класса. Любой output-трансфер может быть соединен с любым input-трансфером — при условии совместимости их флагов, о чем мы поговорим чуть ниже. Это применимо и к тем узлам, которые еще не существуют и будут созданы пользователем.

3. Значение undefined никогда не распространяется

В Transferum undefined означает «нет данных», а не «пустое значение». Оно подавляется на уровне внутренней реализации менеджера подписок — подписчики никогда не уведомляются с undefined. При этом для явных маркеров пустых значений можно использовать null. Мы сознательно пошли на этот компромисс, чтобы избежать runtime-оверхеда и сохранить нативную скорость работы на плотных потоках данных.

Связывание трансферов

Функция linkTransfers(lhs, rhs) соединяет output-трансфер (lhs) с input-трансфером (rhs) с автоматическим выбором стратегии связывания на основе возможностей этих трансферов:

• isSubscribable → isPushable (реактивная подписка);
• isPullable → isPollingProxy (активный опрос);
• isSubscribable → isAsyncPushable (реактивная подписка + асинхронный push);
• isAsyncPullable → isAsyncPollingProxy (активный асинхронный опрос асинхронного pull-источника);
• isPullable → isAsyncPollingProxy (активный асинхронный опрос синхронного pull-источника).

Protocol-oriented design: механизм не спрашивает «какой это класс?» — он выясняет, какие у него есть возможности. Любая пара трансферов с совместимыми возможностями является linkable. Добавление нового класса трансфера требует только объявления его флагов и реализации соответствующих методов — как связать его с другим трансфером, связующий алгоритм разберется сам.

Sync и async в одной экосистеме

Синхронные и асинхронные трансферы сосуществуют и могут быть связаны между собой. linkTransfers() предпочитает sync-связывание, когда это возможно, а async-стратегии применяет только когда sync неприменим. Нет отдельного «асинхронного мира».

Поддержка backpressure

Ряд асинхронных трансферов (AsyncSinkTransfer, AsyncWriteTransfer, AsyncConvertTransfer, AsyncConditionTransfer) поддерживают необязательные поля в конфигурации: maxConcurrency, bufferSize и onBufferOverflow — для ограничения параллельных async-операций, очереди избыточных данных и graceful-обработки переполнения. По умолчанию — неограниченная обработка, без буферизации.

Локальная обработка ошибок

Transferum использует единую модель обработки ошибок для всех трансферов. Каждый трансфер, который может столкнуться с runtime-ошибкой, принимает опциональный onError-хэндлер в своей конфигурации.

А теперь — к примерам использования

Вот так можно просто и декларативно описать опрос и агрегирование данных из нескольких источников:

А вот как можно организовать динамический роутинг:

Пример организации игровой механики:

Когда имеет смысл попробовать Transferum

Библиотека подойдет для:

• TypeScript-first проектов — благодаря максимально строгой типизации и compile-time вычислению доступных методов любого трансфера на основе объявленных у него флагов возможностей.
• Работы с pull-based источниками данных — polling API, датчиков, хранилищ с PollingProxy.
• Смешанных sync/async пайплайнов — в единой модели без ручного преобразования.
• Явного flow control — gates, bridges, selectors для runtime-маршрутизации.
• Game development / IoT — frame-aligned tickers, idle polling, sensor aggregation.
• Устойчивой обработки ошибок — локальная, non-fatal обработка: одна стадия не убивает пайплайн при условии переданного в конфиге обработчика ошибок, ничего не подавляется молча.

Результаты и планы

• Библиотека уже используется в двух наших внутренних проектах и показывает свою эффективность. Код доступен на GitHub под лицензией MIT, библиотека не имеет внешних зависимостей и поставляется с подробной документацией (README + API Reference).
• В одном из проектов граф состоит из ~80 узлов и стабильно обрабатывает несколько сотен событий в секунду без деградации. На основе этих данных в том числе рендерится 3D-сцена в Babylon.js со стабильным фреймрейтом ~60 FPS без микрофризов.
• Тесты библиотеки покрывают не только отдельные трансферы, но и поведение системы в динамике: переподключение мостов, обработку ошибок в длинных асинхронных цепочках, а также разнообразные граничные случаи. Покрытие — 100%.
• В дальнейшем планируем реализовать хуки и утилиты для более удобного и нативного использования Transferum с Vue и React. Если они окажутся в достаточной мере переиспользуемыми, оформим в отдельные пакеты-адаптеры.

Буду рад, если вы заглянете в репозиторий, попробуете библиотеку в деле и поделитесь замечаниями — обратная связь поможет сделать Transferum лучше.

P. S. Если вы сталкивались с похожими задачами и решили их как-то иначе — буду рад прочитать о вашем опыте в комментариях.

Улучшение читаемости кода

Все знают про кошмарные замыкания в Swift. Из-за особенностей мобильной разработки асинхронные процессы должны вызываться вовремя. Раньше это делали с помощью замыканий. Кто-то из вас может до сих пор использовать для этого замыкания и это нормально.

Но однажды вы столкнётесь с вложенными замыканиями. И начнётся кошмар. Читать и редактировать вложенные замыкания — больно. Все это понимают.

И как же реактивное программирование на Swift помогает уменьшить эту боль?

Вы можете связывать observables в цепочки с помощью функций: map, flatMap и flatMapLatest. Таким образом можно обрабатывать запросы одновременно, не утруждая себя чтением вложенных замыканий.

Также функции merge, combine и zip дают возможность выполнять несколько запросов в более управляемом и читаемом виде. Вот цитата о важности хорошей читаемости:

Конечно, соотношение времени потраченного на чтение кода, ко времени потраченному на его написание — примерно 10 к 1. Мы постоянно перечитываем старый код, ведь это часть процесса написания нового. Следовательно, облегчение понимания кода также облегчает и его написание.

Поэтому очень полезно тратить время на то, чтобы сделать ваш код более понятным и читаемым.

Это не означает, что вы должны полностью отказаться от использования замыканий. Однако, используя замыкания вместе с реактивной библиотекой по вашему выбору, вы можете сделать свой код более читаемым.

Помощь с обработкой событий

В общем сценарии iOS-разработки вам нужно реагировать на события из разных частей приложения. Например кто-то изменил своё имя в одном контроллере, и нужно обновить его в другом.

Для таких случаев есть несколько сценариев: делегаты, notifications, и пары ключ-значение. Каждый из них работает неплохо. Но у реактивного подхода есть, что предложить.

Во-первых, реактивное программирование может упростить работу с этими сценариями. Всё, что вам нужно, — это создать observer или subject и подписаться на него. Затем, каждый раз, когда observer порождает объект, все подписчики об этом узнают.

Можно использовать такой синтаксис:

Видите, всё достаточно просто. Для этого не нужно много кода. Как я говорил ранее, один из признаков отличной кодовой базы — она понятна любому.

Вы можете подписаться на subject из первого контроллера в любом месте программы. А затем использовать myObject для своих целей. Например, пропустить первые два объекта. Для этого можно использовать функцию skip. И как я уже говорил, вы можете комбинировать observable с помощью функций merge и zip.

Если вам нужно зацепление, можно использовать протокол и получать через него доступ к subject. Например:

Сделать код более модульным

Одна из моих любых особенностей реактивного программирования — передача observable в качестве переменных. Например можно передать сетевой запрос в другой объект и выполнить его, когда потребуется. Это позволяет сделать код более читаемым и модульным.

Допустим, у вас есть контроллеры, которым требуется observer конкретного типа. Вы можете использовать с ними любые сетевые запросы, observer’ы которых порождают объекты нужного типа.

Я всегда пользуюсь этим, когда мне требуются переиспользуемые контроллеры для отображения данных пользователю. Возьмём приложение, похожее на Instagram, где есть объект поста, и экран, где эти посты отображаются. Вам нужно выводить на одном и том же экране посты одного или другого пользователя. Так как это скорее всего делается с помощью сетевых запросов, вы можете создать запрос как observable и передать его контроллеру. Остальное контроллер сделает сам.

Это фрагмент кода иллюстрирующий мою основную идею:

Таким образом, преимущество здесь заключается в модульности и универсальности. Этот один контроллер можно использовать повторно в любое время, когда вам понадобится отобразить список сообщений. И всё, что вам нужно сделать, — это передать ему observer. Остальное сделает контроллер.

Кроме вышеперечисленных возможностей, реактивное программирование на Swift:

• позволяет эффективно отлаживать код;
• сильно уменьшает количество строк кода;
• при использовании таких библиотек как RxSwift или RxCocoa, даёт возможность использовать traits для лучшего понимания кода;
• хорошо подходит для архитектуры MVVM;
• позволяет выполнять цепочки запросов парой строк кода.

Что такое реактивное программирование?

Классический подход к программированию предполагает выполнение запроса (к базе, сервисам и т.д.), ожидание ответа и продолжение работы. Во время ожидания поток простаивает. Масштабируют такие системы путём увеличения количества потоков, при этом вычисление оптимального количества потоков становится непростой задачей, так как сильно зависит от характера нагрузки, количества и качества ожиданий. И несмотря на это, избежать на 100% простоя ресурсов не удается.

В реактивном программировании обработка делится на большое количество небольших задач, выполнение каждой из которых оканчивается неким событием. На возникновение этого события реагирует соответствующий обработчик и выполняет свою задачу, опять генерирует событие и общий процесс обработки продолжается. Генерация события и реакция на него происходят асинхронно. Обработчик (их ещё называют акторами) выбирает следующее событие из очереди, обрабатывает и складывает событие в очередь другому обработчику. Если задача заключается в выполнении запроса в базе данных, то актор посылает запрос на сервер. После получения ответа будет сгенерировано событие с результатом запроса и запущен соответствующий актор.

Всё это позволяет более эффективно занять ресурсы полезной работой и управлять масштабированием. Повышается отзывчивость приложений. Кроме того, реактивное программирование помогает масштабироваться горизонтально.

Понятие реактивного программирования тесно связано с понятием модели распространения данных, которая бывает двух типов:

1. pull-модель.
2. push-модель.

На самом деле, эти модели вполне логичны и естественны, поэтому их проявления можно проследить даже в обычной жизни.

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

Его коллеге — Пете — тоже интересен хоккей, но в отличие от Васи, Петя подписался на рассылку новостей и получает уведомления о важных событиях в хоккее.

С точки зрения программирования, Вася использует pull-модель: периодически просматривает источники данных, в то время как Петя — push-модель: занимается обработкой входящих сообщений.

Таким образом, реактивное программирование — это стиль написания кода, который упрощает реализацию приложений, основанных на push-модели.

На практике этот стиль применяется для обработки входящего потока данных, например:

• сообщения от пользователей;
• уведомления об изменении расписания;
• действия пользователя с интерфейсом и т.д

Реактивное программирование — это подход к разработке ПО, который строится на реагировании на события и на распространении событий. При этом модель реакции на события предполагает возможность простого распространения этих или трансформированных событий далее по системе. Ярким примером реализации реактивного подхода может служить таблица Excel. В ней существует цепочка вычислений, разделённая на несколько ячеек: при изменении значения одной из ячеек в цепочке значения в зависимых ячейках пересчитываются автоматически.

В целом, идея реактивного программирования призвана упростить создание сложных систем. В сложной большой системе возникает значительное количество разнообразных событий, каждое требует определённого механизма реакции и обработки. При использовании реактивного программирования события объединяются в потоки, а компоненты системы являются обработчиками потока событий (и также в свою очередь могут являться генераторами событий). Таким образом, сколь ни была бы сложна система и сколько бы в ней ни было разнообразных событий, вся система строится по принципу генерации потоков событий и реакции на них. Подход в моделировании сложной системы позволяет обрабатывать каждое событие асинхронно и изолированно от других. Важно понимать при этом, что дизайн реактивной системы предполагает, что любая функциональность в системе реализуется с помощью событий и обработчиков. Благодаря этому достигается уменьшение связанности между компонентами системы, увеличение гибкости, упрощение масштабирования и повышение устойчивости систем.

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

Суть реактивного программирования можно изобразить разными способами. Например, представим реку, течение которой несет несколько разноцветных объектов (мячей). Допустим, на берегу сидит человек, которому нужно выловить объекты с определенной характеристикой – только зеленые или красные. Если нам требуется запрограммировать подобную ситуацию, то реактивный подход – это то, что поможет нам оперировать потоками данных, получать данные, совершать математические вычисления и т.д. Работа с потоками требует от программиста определенного опыта и понимания, что и как комбинировать, какие операторы подходят для решения задачи.

Реактивный подход активно используется в Frontend-разработке и мобильной разработке, одним из его популяризаторов является Netflix.

Само название парадигмы наводит на мысль, что реактивное программирование подразумевает какую-либо реакцию на изменения. Так и есть: реактивное программирование удобно при создании интерфейсов и построении моделей систем, изменяющихся во времени.

Реальным применением этой парадигмы может стать веб-фреймворк, поддерживающий архитектуру MVC (Model-View-Controller), в котором при изменении модели изменяется поведение пользовательских представлений.

Предположим, есть модель Пользователь с полями Имя и Фамилия. Добавляем поле Отчество — и во всех местах, будь это форма на сайте или структура базы данных, происходят соответствующие изменения: форма при следующей генерации содержит новое поле, а для БД генерируется миграция.

В рамках парадигмы чаще всего используют функции обратного вызова (callback) и конструкции асинхронного программирования (конкретные виды зависят от языка). Также здесь задействуют события (events) или потоки (flows). Если в коде есть такие «следы», значит, с большой вероятностью здесь применяется концепция реактивного программирования

Итак, что из себя представляет реактивное программирование?

В реактивном программировании обработка делится на большое количество небольших задач, выполнение каждой из которых оканчивается неким событием. На событие реагирует обработчик, который выполняет свою задачу и снова генерирует событие. Генерация события и реакция на него происходят асинхронно.Идея реактивного программирования призвана упростить создание и масштабирование сложных систем.Примером реактивного подхода может служить таблица Excel. В ней существует цепочка вычислений, разделённая на несколько ячеек: при изменении значения одной из ячеек значения в зависимых ячейках пересчитываются автоматически.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Эта статья не ставит своей целью описание фреймворков и архитектуры, поскольку они и так достаточно хорошо задокументированы. Скорее, она предназначена для тех, кто начинает работу с микросервисами и Project Reactor, и описывает основные особенности указанных технологий и то, с чем придётся столкнуться и работать.

В отличие от монолитной, микросервисная архитектура основана на выделении небольших независимых служб, каждая из которых реализует отдельную бизнес-функцию. Если в монолите всё связано (и в случае отказа одной функции могут «отвалиться» остальные), то микросервисы позволяют обеспечить гибкость и устойчивость системы. Крупные IT-решения могут содержать в своей архитектуре десятки микросервисов, и с каждым из них может работать отдельная независимая команда.

Пример

Рассмотрим на примере кейса из нашей практики. Страховая компания обратилась к нам для модернизации своего онлайн-приложения, имеющего гибкую микросервисную архитектуру. Перед нами стояла задача реализовать в приложении кэшбэк, то есть начисление пользователю бонусных баллов за покупку страхового полиса.

На первый взгляд, задача выглядела просто.

1. За каждый оплаченный (продлённый) полис начислять пользователю определённый кэшбэк X% через бухгалтерский сервис. Пользователю должна быть доступна информация о поступившем кэшбэке.
2. По достижении определённого суммарного кэшбэка автоматически переводить средства клиенту через бухгалтерский сервис. Пользователю должна быть доступна история выплат.

Основной проект использовал очередь сообщений Kafka в качестве средства обмена информацией между микросервисами, а также в качестве единственного перманентного реплицированного хранилища информации.

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

Добавим также, что клиентов у такого приложения предположительно неограниченно много. И многие из них — мобильные, т. е. относительно медленные.

Blocking vs Non-blocking

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

Но, во-первых, не всегда есть возможность приобрести такой сервер. Во-вторых, и это самое главное, что-то всегда может пойти не так. Например возникнут какие-либо задержки бэка или проявится ситуация «retry storm» — когда множество пользователей приложения из-за недоступности функций инициируют повторные попытки запроса со своих устройств. Тогда количество активных соединений и потоков увеличивается. В этом случае кластерные ноды могут попасть в спираль — резервные копии потоков увеличивают нагрузку на сервер и перегружают кластер. Конечно, можно встроить механизмы регулирования, чтобы компенсировать риски и помочь поддержать стабильность во время этих событий, но понятно, что это не панацея. Кроме того, восстановление может быть достаточно долгим и рискованным.

Асинхронные системы работают по-другому. В них обычно одному ядру соответствует один поток, а цикл запроса-ответа обрабатывается через события и коллбэки. Получается, что там, где мы раньше «платили» за запрос целым потоком, теперь просто добавляется ещё одно сообщение.

Понятно, что и восстановление после различных задержек бэка или «retry storm» даётся легче — обработать дополнительные сообщения в очереди гораздо проще, чем складировать кучу потоков. И поскольку все запросы асинхронны, упрощается масштабируемость системы. Если мы видим большое количество сообщений в очереди, то мы просто временно создаём дополнительных потребителей.

Устойчивость системы достигается за счёт самой природы асинхронного подхода. Во-первых, мы, конечно, можем попробовать обработать исключение локально. А во-вторых, и это главное, в асинхронных системах компоненты не блокируются обработкой исключений: ошибка в одном компоненте не влияет на остальные. Более того, если один компонент не справляется с обработкой сообщения, то сообщение может быть обработано другим компонентом, записанным на этот же адрес.

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

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

Согласно требованиям заказчика, реализовать проект нужно было на Java для удобства его дальнейшей поддержки. Распространённых вариантов высокоуровневых абстракций было не так уж и много, поэтому мы остановились на Project Reactor.

Работа с Project Reactor

Reactor — реализация спецификации Reactive Streams, об этом вопросе уже достаточно подробно рассказывали.

Несмотря на обилие документации по Reactor, всё же отдельно хотелось бы отметить одну из особенностей при работе со стримами Reactor. В Reactor есть 2 основные структуры данных — Flux и Mono. Обе они являются реализациями интерфейса Publisher и представляют собой асинхронный поток элементов, либо единичный асинхронный элемент соответственно.

Стримы в Reactor внешне очень похожи на стандартные стримы Java по коллекциям (java.util.stream.Stream). В Java, конечно, Stream — это не только и не столько механизм работы с коллекциями. Но тут важно помнить, что Flux — это тем более не коллекция.

В Java перед началом стрима по коллекции у нас есть все её элементы, мы знаем её размер и т. п. Flux же лучше рассматривать как некую отложенную коллекцию, количество элементов которой на момент выполнения стрима неизвестно.

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

Схема работы

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

Мы видим, что у приложения есть 3 основных процесса:

1. Получение информации извне (полисы, пользователи, оплата) и начисление кэшбэка на её основе. Это будет первый сервис — «Калькулятор».
2. Общение с пользователем. Приложение обращается к хранилищу, чтобы по определённому пользователю найти нужный кэшбэк. Это будет второй сервис — «Хранилище».
3. Общение с бухгалтерским сервисом. Начисление кэшбэка и выплаты должны быть проведены через этот сервис. Это будет третий сервис — «Бухгалтер».

Итак, схема довольно простая:

«Калькулятор» вычисляет кэшбэк по каждому полису/пользователю/факту оплаты и отправляет сообщение в отдельную очередь. Сервисы «Хранилище» и «Бухгалтер» читают сообщения из этой очереди. «Хранилище» сохраняет кэшбэк и показывает его пользователю, а в случае достижения минимального порога выплаты — инициирует зачисление средств на карту пользователя. «Бухгалтер» вызывает внешний бухгалтерский сервис для физического начисления бонусов.

Организация локального хранилища

Особое значение имеет очерёдность этих процессов. Мы видим, что наш «Калькулятор» работает на основе сообщений от внешних сервисов. Возможны ситуации, когда «Калькулятор» на основе одного входящего сообщения не сможет принять решение об отправке. Например, ему нужно проверить 2 внешних топика: полисы и оплату. В этом случае необходимо внутреннее хранилище, которое мы формируем на основе всех внешних сообщений.

Сравнивая стандартные SQL варианты (PostgreSQL, MySQL) и NoSQL подход, мы в этом проекте в качестве локального хранилища, решили отдать предпочтение MongoDB по нескольким причинам:

1. Для mongoDB есть готовый фреймворк по работе с Project Reactor — reactive mongo.
2. Малое количество таблиц и связей между ними.
3. Простота использования, нет необходимости следить за соответствием моделей таблицам БД.

И конечно, нам нужно разделить процессы формирования локального хранилища и принятия решения об отправке. Как это сделать, если решение об отправке принимается на основе тех же сообщений, по которым строится внутреннее хранилище? Одним из возможных вариантов является разделение по времени и запуск начисления по внешнему планировщику. Мы остановились на этом способе реализации, простом и понятном.

Репроцессинг

Для того, чтобы упростить архитектуру приложения и снизить возможные риски, желательно использовать микросервисы stateless, без локальных хранилищ. То есть вне зависимости от того, какая информация на входе, она просто проходит по цепочке стрима.

Если это невозможно по тем или иным причинам, можно попробовать изолировать в отдельном слое логику работы с состоянием. Иначе говоря, поставить над логикой с состоянием дополнительный уровень абстракции. В этом случае в приложении есть сегмент statefull, но он изолирован, другие части не связаны с состоянием.

Однако на практике с этим могут возникать сложности. Например, не позволяет архитектура, нет времени или понимания, как это лучше сделать в конкретном проекте, не позволяют требования репроцессинга. При выключении и включении сервиса (и сбросе оффсетов) такой сервис будет повторно выполнять уже сделанные действия. То есть в нашем случае «Калькулятор» будет повторно отбрасывать сообщения о начислении кэшбэка. Более того, даже локальное хранилище не гарантирует правильной работы, поскольку оно не реплицировано и может быть полностью удалено в любой момент вместе с сервисом.

Один из вариантов решения — использовать специальную очередь отправленных сообщений. Эту очередь мы будем читать и записывать в локальное хранилище на старте сервиса, вместе со всеми остальными внешними сообщениями.

Прочие особенности

Ещё одна особенность Project Reactor при работе с фронтом заключается в том, что в большинстве случаев нам недостаточно просто получить какое-либо значение. Чаще нам нужно получить значение и затем отслеживать его изменения. Этот вопрос достаточно просто решить с помощью reactive mongo. У хранилища из библиотеки reactive mongo есть методы получения и отслеживания, которые вернут не только требуемое значение, но и все его последующие изменения, если таковые будут.

Также обратим внимание на сервис «Бухгалтер». Предположим, что этот сервис работает с внешним API по REST или, как в нашем случае, по SOAP. Здесь также действуют требования по репроцессингу, и нужна отдельная очередь истории. Но также возможны и дополнительные требования по устойчивости системы в целом.

Например, что будет, если внешний API ответит 500 ошибкой? В нашем случае мы можем воспользоваться стандартным механизмом Reactor .retryBackoff() — он попробует отправить сообщение ещё несколько раз, увеличивая задержку между повторными сообщениями. Можно также настроить стрим на отлавливание определённых ошибок и реагировать только на них. Подробнее можно посмотреть тут.

Тестирование

Конечно, на создании рабочих модулей проект не заканчивается. Нам нужно проверить его работоспособность, в частности с помощью юнит-тестов. Для модулей на Project Reactor в юнит-тестах используют StepVerifier — это внутренний компонент, который позволяет правильно протестировать функциональность. Документация по StepVerifier легко доступна и полноценна.

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

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

Вывод

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

Хотя реактивная реализация не всегда увеличивает быстродействие системы, однако значительно улучшает её масштабируемость и устойчивость.

Использование Reactor позволяет достаточно просто реализовать асинхронную работу, сделать решение более наглядным и понятным для дальнейшей поддержки. При этом работа с Project Reactor потребует особого внимания при написании кода, а именно при выстраивании стримов Flux и Mono, также необходимо всегда сверяться с документацией и проводить промежуточные тесты.

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

Место проведения и немного истории

В этом году JFuture прошла в VOKA Cinema by Silver Screen — одном из самых больших мультиплексов Минска. Такое неочевидное место выбрано не случайно: всё дело в самой концепции мероприятия.

JFuture родилась из международной конференции Java Day, проводимой при поддержке Oracle во многих городах мира. Java Day проводилась на регулярной основе, но в один прекрасный момент организаторам наскучили серьёзные академические доклады о спецификациях, многопоточности и проблемах с памятью, и они захотели сделать что-то самобытное и живое. Так, на стыке JVM, науки и искусства родилась конференция JFuture. Впервые она прошла в 2018 году в одном из старейших театров Беларуси — Национальном Купаловском театре. И, конечно, логичным развитием места проведения стал теперь уже кинотеатр, причём самый технологичный из существующих в Минске.

К тому же, где ещё вы сможете послушать лекции по Java с попкорном, в удобных креслах и на большом экране?

Организация

На входе нас встретили дружелюбные волонтёры, которые рассказали о некоторых организационных моментах и ответили на вопросы. Уже потом мы выяснили, что за прошедшие сутки они спали всего пару часов.

Проходы были узкими, но столпотворений не возникало благодаря грамотному расположению стендов с активностями и других важных точек. Более того, из-за камерности площадки в коридорах можно было запросто встретить кого-нибудь из спикеров и поговорить по душам, задать интересующие вопросы или просто вместе выпить кофе.

Доклады

С приветственным словом публику встретила главный организатор конференции Дарья Милько из SPACE_. Она поздравила участников с открытием и рассказала, как пройдёт мероприятие, а затем дала слово первому спикеру. Кстати, выступала Дарья, как и остальные спикеры, на английском.

Конференция прошла в два потока, с полным списком докладов можно ознакомиться на странице JFuture. Мы расскажем только о тех выступлениях, которые смогли посетить.

Uncovering Project Amber

Открыла конференцию Мала Гупта, Developer Advocate из JetBrains, с докладом о проекте Amber. Она начала своё выступление с введения в саму инициативу, её целях и методах улучшения Java. Затем спикер описала изменения, уже вошедшие в стандарт языка благодаря усилиям проекта: и вывод типов локальных переменных с помощью var, и switch-выражения, представленные в Java 13.

После началось самое интересное — Мала рассказала о новых фичах и возможностях, которые только планируется внедрить в Java. Среди них:

• sealed типы и новое ключевое слово Record, позволяющее избавить разработчика от написания boilerplate-кода типа геттеров, сеттеров, методов toString() и equals();
• перечисления с внутренними переменными и даже generic-перечисления;
• «сопоставление с образцом» для упрощения языковых конструкций вида if (obj instanceof Obj) {...};
• однострочные методы с синтаксисом, заимствованным у лямбда-функций.

В заключении Мала сделала важный вывод: «Изменения постоянны — просто примите это». Ведь языки программирования, как и любые другие, постоянно видоизменяются и улучшаются под стать окружающему миру.

Первый доклад задал тон всей конференции — все её участники настроились на изучение новых подходов, технологий и способов создавать более эффективные решения.

Efficient web apps with Spring Boot 2

Стефан Николл из Pivotal затронул очень болезненную для многих Java-разработчиков тему повышения производительности и скорости работы веб-приложений. Безусловно, оптимизировать можно очень долго: рефакторить код, находить узкие места в сетевой инфраструктуре и ускорять работу баз данных. Но так ли это нужно, если в большинстве случаев выигрыш в производительности не стоит всех затраченных на улучшение этой самой производительности средств? К такому выводу и пришёл спикер, представив публике быстрый и эффективный способ оптимизации с помощью Project Reactor. Это кроссплатформенный проект, предоставляющий API для работы с реактивными стримами.

Стефан много кодил сам, попутно объясняя, что значит та или иная строчка кода, и показывал происходящие с приложением изменения в режиме реального времени с помощью софта для метрик Prometheus. В конце доклада ему удалось значительно уменьшить задержки в отдельных запросах и продемонстрировать полностью рабочий прототип приложения на Spring WebFlux. Конечно, не обошлось и без ограничений реактивного стека: например при использовании WebFlux все микросервисы и драйверы должны быть реактивными. Это значит, что вы не сможете пользоваться Spring Data JDBC или JPA.

JVMs in Containers: Best Practices

Следующий посещённый нами доклад дал качественную вводную о лучших практиках работы с проектами на JVM-платформе в контейнерах.

Несмотря на хардкорную техническую составляющую большинства докладов, спикеры держались непринуждённо и старались стать ближе к аудитории. Вот Дэвид Делабассе из Oracle и начал выступление с дисклеймера: разработчик не преминул пожаловаться на клавиатуру новых MacBook — в ней то и дело залипали клавиши. Когда все отшутились и посетовали на проблемные лэптопы, спикер рассказал о разнице между контейнерами и виртуальными машинами:

Когда с ликбезом было покончено, началась самая интересная часть выступления — живой кодинг. Дэвид начал со сборки контейнера с банальным «Hello, world», однако тут же возникла неожиданность — образ «весил» больше 300 Мбайт.
Конечно, сделано это было не просто так. Спикер показал зрителям, как с помощью нехитрых манипуляций с рабочей версией JDK и флагами сборки Docker-файла получилось уменьшить размер более, чем в 15 раз — до 17 Мбайт!

В конце выступления спикер отметил, что для работы с контейнерами и JVM определённо больше подходят дистрибутивы Linux или MacOS. Кроме того, он остановился на преимуществах GraalVM, который упрощает и ускоряет сборку проектов.

The State Of Reactive Streams

Олег Докука, евангелист реактивных стримов, провёл экскурсию в историю реактивного программирования: от зарождения концепции в 1970-х годах в работах сотрудников Microsoft до настоящего времени.

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

Кроме насыщенной программы и харизматичного докладчика внимание цеплял ещё и рисованный гусь, который «жил» на просторах презентации:

Благодаря юмористическим вставкам и миниатюрам с его участием информация воспринималась намного проще.

Live Coding Music 101

Заключительным стало выступление Петра Ягельского из TouK. Он показал, как с помощью вашего любимого языка программирования и MIDI-контроллера можно играть настоящую электронную музыку. И не просто показал, а сыграл несколько электронных композиций «на лету».

Пётр рассказал о самой концепции Live Coding Music и ударился в технические детали синтеза звуков с помощью цифровых сигналов и специализированного ПО. Кроме того, спикер подсказал ресурсы, на которых можно найти бесплатные музыкальные сэмплы.

Выступление отчасти смазала общая возбуждённость аудитории — после финального доклада организаторы пообещали разыграть призы — и заметное волнение спикера. Однако это не помешало послушать электронную музыку и узнать о таком необычном направлении.

Другие активности

Конечно, что за конференция без стендов с партнёрами и клёвыми ништяками?

На площадке JFuture расположились минские и международные компании Kyriba, Playtika, ISsoft, EIS Group и JetBrains. Их представители были готовы пообщаться и позадавать интересные вопросы и задачки, за решение которых можно было получить приятные подарки. Например термокружки, фрисби, йо-йо и наборы значков. И, конечно, тонны стикеров для лэптопа (кажется, скоро придётся завести специальный альбом для них, потому что место на крышке стремительно заканчивается). А Kyriba даже разработала онлайн-квест с вопросами по разным сферам IT, алгоритмам и языкам программирования. За победу в нём можно было выиграть футболку и принять участие в розыгрыше.

Кроме технических задачек Playtika, Kyriba и ISSoft запустили розыгрыш ценных призов, который шёл в течение всего дня. Для участия нужно было либо просто оставить свои данные, либо, в случае с Kyriba, заработать определённое количество баллов в онлайн-квесте.
Призы были действительно стоящими: PS4 Pro, SSD на 1 Тбайт и автономный робот.

Заключение

Организаторам из SPACE_ удалось выйти на уровень топовых международных конференций и привезти в Минск действительно интересных и выдающихся спикеров. Кроме всего прочего, плюсом конференции стала её камерность, за счёт чего все участники могли свободно пообщаться и поговорить о наболевшем со специалистами в непринуждённой обстановке.

Конференции и митапы — это всегда отличная возможность быть в курсе того, чем живёт IT-сообщество, узнать о новых техниках и практиках, а также завести новых знакомых и партнёров. Тем более когда в ваш город приезжают именитые разработчики и евангелисты технологий со всего мира.

Кстати, участие в IT-мероприятиях — это плюс не только для вас, но и для вашего начальства. Ведь специалист, который развивается и живёт, постоянно обучаясь, всегда на хорошем счету. Следите за нашими анонсами в разделе событий и приобщайтесь к международному сообществу программистов!

Этот материал направлен на то, чтобы помочь новичкам начать думать по-настоящему “реактивно”.

Так что же такое реактивное программирование?

Есть множество не до конца верных определений и объяснений в интернете. Википедия дает слишком скупое описание. Ответы на Stack Overflow часто непонятны новичкам. Реактивный Манифест выглядит так, будто его писали для руководителей проектов или бизнесменов. Rx терминология от Microsoft, гласящая о том, что “Rx = Observables + LINQ + Schedulers”, звучит настолько тяжело и по-майкрософтовски, что большинство из нас слабо понимает, о чем идёт речь. Такие термины, как “реактивность” и “распространение изменений” не выражают ничего, что бы отличалось от обычного MV* подхода, реализованного уже на бесчисленном множестве языков. Любой фреймворк реагирует на изменения моделей. В любом фреймворке изменения распространяются. Если бы это было не так, пользователь не видел бы никаких изменений.

Дадим подробное объяснение термину “реактивное программирование”.

Реактивное программирование — программирование с асинхронными потоками данных

Впрочем, ничего нового. Event bus’ы или обычные события клика — это тоже асинхронные потоки данных, которые вы можете прослушивать, чтобы реагировать какими-либо действиями. Реактивность — это та же самая идея, возведенная в абсолют. Вы можете создавать потоки данных не только из событий наведения или кликания мышью. Потоком может быть что угодно: переменные, пользовательский ввод, свойства, кэш, структуры данных и т.п. Например, представьте, что ваша лента новостей в Твиттере — поток событий. Вы можете слушать этот поток и реагировать на события соответственно.

Кроме этого, вы получаете удивительный набор функций для комбинирования, создания и фильтрации этих потоков. Вот где проявляется вся магия этого подхода. Один или несколько потоков могут использоваться как входные данные для другого потока. Вы можете объединять два потока. Также вы можете фильтровать поток, выбирая только те события, которые вам интересны.

Так как потоки — основопологающая вещь в реактивном подходе, давайте рассмотрим их подробнее на примере пользовательского клика мышью:

Поток — это последовательность событий, упорядоченная по времени. Он может выбрасывать три типа данных: значение (определенного типа), ошибку или сигнал завершения. Сигнал завершения распространяется, когда текущее окно или окно, содержащее кнопку, закрывается.

Мы перехватываем эти события асинхронно, указывая одну функцию, которая будет вызываться, когда выброшено значение, другую для ошибок и третью для обработки сигнала завершения. В некоторых случаях можно опустить последние две и сфокусироваться на объявлении функции для перехвата значений. Прослушивание потока называется подпиской (subscribing). Функции, которые мы объявляем, называются наблюдателями (observer). Поток — это объект наших наблюдений (observable, наблюдаемый объект). Это в точности паттерн проектирования, называемый “Наблюдатель“. Подробнее о шаблонах проектирования для новичков, читайте в нашей статье.

В данном руководстве мы будем использовать альтернативный способ представления вышеупомянутой диаграммы с помощью ASCII символов:

Теперь давайте сгенерируем новые потоки сообщений клика, трансформированные из оригинального потока.

Для начала сделаем поток счетчиков, который определяет, сколько раз кнопка была нажата. В большинстве реактивных библиотек у каждого потока есть множество встроенных функций, таких как map, filter, scan и т.д. Когда вы вызываете одну из этих функций, например clickStream.map(f), она возвращает новый поток, основанный на родительском. Функции не модифицируют родительский поток. Это называется неизменяемостью и является неотъемлемой частью реактивного подхода, позволяя нам вызывать цепочку функций, например clickStream.map(f).scan(g):

Функция map(f) заменяет каждое полученное значение в соответствии с вашей реализацией функции f. В нашем случае функция map производит значение “1” после каждого клика. Функция scan(g) аггрегирует все предыдущие значения, производя значение x = g(accumulated, current), где g в данном случае — это просто функция сложения. В конечном итоге counterStream выбрасывает общее количество кликов.

Чтобы вы поняли всю мощь реактивного подхода, давайте предположим, что вы хотите реализовать поток событий “двойной клик”. Чтобы сделать эту задачу еще интереснее новый поток должен принимать множественные нажатия за двойные. Представьте себе, как бы вы реализовывали эту задачу в императивном стиле. Потребовалось бы несколько переменных, хранящих состояние, и использование интервалов.

В реактивном же подходе все достаточно просто. Всю описанную выше логику можно реализовать четырьмя строками кода. Но давайте пока не останавливаться на коде. Лучший способ научиться понимать и проектировать потоки, вне зависимости от того, новичок вы или эксперт — это изображать диаграммы:

Серые прямоугольники — это функции, которые трансформируют один поток в другой. Сначала мы собираем клики в списки. Если прошло 250 миллисекунд без единого нажатия кнопки — мы применяем функцию map() на каждом из списков, чтобы вычислить его длину. В конце мы фильтруем списки с длиной 1, используя функцию filter(x >= 2). Вот так, в три действия, мы получаем результат — поток событий множественных кликов. Мы можем подписаться на него и использовать, как пожелаем.

Этот пример показывает всю простоту, с которой реализовывается достаточно сложная на первый взгляд задача, если мы используем реактивный подход.

Для чего нужно реактивное программирование

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

Преимущество более заметно в современных веб- и мобильных приложениях, которые работают с большим количеством разнообразных UI-событий. 10 лет назад всё взаимодействие с веб-страницей сводилось к отправке больших форм на сервер и выполнении простого рендеринга в клиентской части. Сейчас приложения более сложны: изменение одного поля может повлечь за собой автоматическое сохранение данных на сервере, информация о новом “лайке” должна отправиться другим подключенным пользователям и т.д.

Реактивное программирование очень хорошо подходит для обработки большого количества разнообразных событий.

Начинаем думать в реактивном стиле

В последующих примерах используется JavaScript и RxJS, но Rx-библиотеки доступны для многих других языков и платформ (.NET, Java, Scala, Clojure, JavaScript, Ruby, Python, C++, Objective-C/Cocoa, Groovy, и т.д.). На нашем сайте есть руководства по использованию библиотек RxSwift и ReactiveX в Python.

Реализуем виджет “На кого подписаться”

В Twitter есть такой виджет, который предлагает вам другие аккаунты, на которые вы можете подписаться:

Мы намерены реализовать его основную функциональность:

• Загрузка из API и вывод трех аккаунтов;
• По клику кнопки “Обновить” вывод других трех аккаунтов;
• По клику кнопки “x” рядом с аккаунтом — удаление его из виджета и вывод другого аккаунта;
• Отображение аватарки и ссылки на аккаунт в каждой из трех строк.

Вместо Twitter-аккаунтов, которые закрыты для неавторизованных пользователей, мы будем использовать Github API и брать аккаунты оттуда. Ссылку на Github API для получения списка пользователей вы можете найти в официальной документации. Также можете смотреть на готовый код данного примера.

Запрос и ответ

Как подойти к решению этой проблемы в Rx-стиле? Надо начать с того, что (почти) все, что угодно может быть потоком. Первое, что мы реализуем, будет “Загрузка из API и вывод трех аккаунтов”. Ничего необычного, нужно просто (1) сделать запрос, (2) получить ответ, (3) отобразить ответ. Представим запрос в качестве потока.

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

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

Создать поток, содержащий одно значение, очень просто с библиотеками семейства Rx*:

То, что мы написали — это просто поток, содержащий строку, который не делает ничего, так что мы должны как-то заставить его действовать так, как нам нужно. Это делается с помощью подписки на поток:

Заметьте, что мы используем Ajax-коллбэк (callback) из библиотеки jQuery, чтобы управлять асинхронностью операции запроса. Если вы слабо понимаете, что такое callback’и, почитайте нашу статью об эволюции асинхронного программирования в JS. “Но подождите, Rx же работает с асинхронными потоками данных. Не может ли ответ на запрос быть потоком, содержащим данные, которые придут когда-нибудь позже?” — можете спросить вы. Что ж, на концептуальном уровне все верно, давайте попробуем это реализовать:

Rx.Observable.create() создает пользовательский поток данных, информируя каждого подписчика о событиях (onNext()) или ошибках (onError()). Мы обернули Ajax-промис в соответствующий коллбэк. Значит ли это, что Promise — то же самое, что Observable? Да, значит. Подробнее о Promis’ах читайте в нашей вводной статье.

Observable — это Promise++. В Rx вы можете конвертировать Promise в Observable очень простым образом:

Единственное отличие между Promise и Observable в том, что Observable не совместим с Promises/A+. Promise — это, по сути, Observable с одним генерируемым значением. Потоки в Rx расширяют промисы, позволяя возвращать множество значений.

Возвращаясь к нашему примеру: вы можете заметить, что мы вызываем функцию subscribe() два раза — один внутри другого. Также создание responseStream зависит от requestStream. Как было сказано выше, в Rx есть простые механизмы, позволяющие трансформировать и создавать новые потоки из других, так что мы должны этим воспользоваться.

Одна из таких функций, с которой вы уже познакомились — map(f) — берет каждое значение из потока A, применяет на нем f() и производит значение для потока B. Если мы применим эту функцию на потоке запроса и ответа, мы можем преобразовать список URL’ов в промисы ответа.

Затем мы должны создать поток потоков, называемый так же метапоток (metastream). Не пугайтесь, все достаточно просто. Метапоток — это такой поток, в котором каждое генерируемое им значение является потоком. Можно представить их себе как указатели: каждое генерируемое значение — указатель на новый поток. В нашем примере URL каждого запроса преобразуется в указатель на поток, содержащий промис ответа.

“Но зачем же нам обернутые в потоки ответы?” — можете спросить вы. В данном случае можно преобразовать метапоток в обычный поток ответов сервера, в котором каждое генерируемое значение является JSON-объектом, а не промисом, с помощью функции flatmap(). Но, тем не менее, метапотоки — обычное явление в реактивном программировании, и в частности, они используются для обработки асинхронных запросов.

Как и ожидалось, если у нас впоследствии будут какие-то события, генерируемые потоком запросов, поток ответов будет реагировать на них соответствующим образом:

И теперь, когда у нас есть поток ответов, мы можем отрендерить получаемые данные:

Весь код целиком:

Кнопка обновления

Нужно отметить, что список пользователей, который мы получаем по API, состоит из 100 элементов. API позволяет нам задавать смещение списка, но не его размер, так что пока мы используем только 3 объекта, игнорируя остальные. Вы научитесь кэшировать ответ чуть позже.

Каждый раз, когда пользователь нажимает кнопку обновления, поток запросов должен сгенерировать URL, чтобы мы могли получить новые данные. Для этой задачи нам потребуется сделать две вещи: реализовать поток событий нажатия на кнопку, а также изменить поток запросов так, чтобы он реагировал на события потока нажатий. К счастью, RxJS позволяет нам преобразовать обычные JavaScript-события в Observable.

Давайте поменяем поток запросов так, чтобы при нажатии кнопки обновления генерировался URL со случайным параметром смещения списка.

Похоже, мы что-то сломали. Теперь запрос срабатывает только после того, как мы нажали кнопку. Но по условию задачи мы должны делать запрос и при инициализации. Давайте попробуем починить наш код.

Для начала создадим разные потоки для вышеупомянутых условий:

Но как же теперь соединить события этих двух потоков в один? В этом нам поможет функция merge(). Вот визуальное представление того, что она делает:

Ну, теперь все очень просто:

Также есть альтернативный и более чистый способ реализовать задачу без вспомогательных переменных:

А можно и еще короче!

Функция startWith() делает как раз то, что нам нужно. Не важно, как вы реализовали поток: если вы вызвали функцию startWith(x), x будет начальным значением.

Вы заметили, что у нас дублируется URL? Давайте избавимся от дубликата, передвинув startWith() поближе к refreshClickStream, чтобы эмулировать нажатие кнопки при инициализации приложения:

То, что надо!

Моделируем 3 рекомендации с помощью потоков

Теперь, вместе с кнопкой обновления, у нас появилась проблема: при нажатии этой кнопки текущие 3 рекомендации не исчезают. Новые предложения появляются, как только с сервера пришел ответ, но для того, чтобы наш UI выглядел отзывчивым, мы должны очищать текущие предложения сразу же.

Теперь у нас есть два подписчика, влияющих на DOM-элементы (другой подписывается на responseStream) и это соответствует принципу “Разделяй и властвуй“. Вы еще помните мантру реактивного подхода? Напоминаем:

Давайте сделаем так, чтобы рекомендации были потоками, в которых каждое генерируемое значение — это JSON-объект, содержащий данные рекомендации. Мы сделаем по потоку на каждую из трех рекомендаций. Вот так выглядит поток для рекомендации №1:

Скопипастим этот код для потока №2 (suggestion2Stream) и №3 (suggestion3Stream). Подумайте над тем, как можно избежать дублирования кода в данном примере. Это будет отличным упражнением. А еще и очень хорошим способом избежать эффекта последней строки.

Вместо того, чтобы рендерить данные в методе subscribe() потока responseStream, мы сделаем это здесь:

Теперь мы можем обнулять рекомендацию при нажатии кнопки обновления:

Этот код будет интерпретировать null, как “нет данных” и скрывать DOM-элемент.

Вот диаграмма того, что мы только что реализовали:

В данном случае N — это null.

В качестве бонуса мы также можем выводить “пустые” рекомендации при инициализации с помощью startWith(null):

Удаление рекомендации и кэширование ответа сервера

Последняя функция, которую мы реализуем — удаление рекомендации. Напротив каждой рекомендации есть кнопка удаления, которая закрывает текущую рекомендацию и показывает вместо неё новую. Первая мысль, которая может у вас возникнуть — нужно делать новый запрос по нажатию этой кнопки:

Это не сработает. Перезагрузятся все рекомендации. Существует несколько способов решения этой проблемы, и один из наиболее оптимальных — повторное использование предыдущего ответа сервера. Ответ API состоит из списка длиной в 100 элементов, из которых мы используем только 3. Нет надобности запрашивать новые данные, когда мы можем использовать 97 “свежих”.

Когда происходит нажатие кнопки “close1”, нам нужно использовать наиболее свежий ответ сервера, чтобы получить случайного пользователя из списка. Примерно так:

В Rx* есть функция-комбинатор combineLatest, которая принимает два потока A и B в качестве входных данных и, когда один из потоков генерирует значение, возвращает два наиболее свежих значения из A и B. Посмотрим на диаграмму того, что она делает:

Мы можем применить функцию combineLatest() на потоках close1ClickStream и responseStream для того, чтобы после клика по кнопке “close1” мы получали последний ответ сервера и генерировали новое значение в suggestion1Stream. С другой стороны combineLatest() симметрична: когда новый ответ генерируется в responseStream, он будет скомбинирован с последним кликом “close 1” и выведет новую рекомендацию. Это позволяет нам упростить наш код suggestion1Stream, который мы писали ранее:

В этой схеме не хватает только одной детали: combineLatest() использует наиболее свежие данные из двух источников, но если один из источников еще не сгенерировал ни одного значения, combineLatest() не произведет события в поток вывода. Если вы посмотрите на диаграмму выше, вы можете заметить, что на выходе ничего нет, когда первый поток генерирует значение a. Только когда второй поток генерирует значение b, на выходе появляется значение.

Есть несколько способов решения этой проблемы и мы воспользуемся простейшим: симулированием клика кнопки “close1” при инициализации:

Все, курс молодого бойца по реактивному программированию окончен! Вы можете взглянуть на рабочий код.

Заинтересовавшись темой функционального программирования, я встал на распутье: какой фреймворк выбрать для ознакомления? ReactiveCocoa — ветеран в iOS-кругах, информации по нему вдоволь. Но он вырос из Objective-C, и хотя это не является проблемой, все же в данный момент я в основном пишу на Swift, и хотелось бы взять решение, изначально спроектированное с учетом всех плюшек этого языка. RxSwift же — порт Reactive Extensions; последний, конечно, имеет долгую историю, но сам порт свежий и написан как раз под Swift. На нем я и решил остановиться.

Как выяснилось, документация по RxSwift несколько специфична: описание всех команд ведет на http://reactivex.io/, а там в основном дается общая информация, у разработчиков еще не дошли руки сделать документацию именно для RxSwift, что не всегда удобно. Некоторые команды имеют тонкости в реализации, а есть такие, о которых в общей документации нет ничего, кроме упоминания.

Прочитав все главы вики с гитхаба RxSwift, я решил сразу поразбираться с официальными примерами; тут-то и стало ясно, что с RX такое не пройдет, нужно хорошо понимать основы, иначе будешь как мартышка с копипастом гранатой. Я начал разбирать самые сложные для понимания команды, а потом перешел к тем, что были вроде и понятны, но задавая себе вопросы по ним, я лишь догадывался, как верно ответить, и уверенности в моих ответах у меня не было.

В общем, я решил проработать все операторы RxSwift. Лучший способ что-то понять в программировании — запустить код и посмотреть, как он отработает. Учитывая специфику реактивного программирования, лучше дополнить это схемами (они бывают очень полезны), ну и кратким описанием на русском. Закончив сегодня работу, я подумал, что грех не поделиться результатами с тем, кто лишь присматривается к теме реактивного программирования.

Много картинок и текста ниже, очень много!

Предварительно я рекомендую просмотреть официальную документацию, у меня передана основная суть и специфика RxSwift команд, а не основы.
Так же можно “поиграться” с шариками в схемах, так называемые RxMarbles, есть бесплатная версия под iPhone/iPad.

Итак, в этой статье я рассмотрю все (ну или почти все) команды RxSwift, дам для каждой краткое описание, схему (если это имеет смысл), код, результат выполнения, а при необходимости сделаю комментарии по выводу в лог результатов выполнения кода.
В статье заголовок каждой команды — ссылка на на официальную документацию, т.к. я не ставил перед собой цели перевести все нюансы по командам.
Вот и ссылка конкретно на PDF, где в виде mindMap собраны все команды, что позволяет быстро просмотреть их все. Кусочки кода в PDF приложены для того, чтобы увидеть, как и с каким параметрами нужно работать с командой. Изначально ради этого PDF я все и затеял — чтобы иметь под рукой документ, в котором наглядно видны все команды с их схемами. PDF получился огромным (в плане рабочего пространства, а не веса), но я проверял, даже на iPad 2 все нормально просматривается.

Обо всех ошибках просьба писать в личку, объем работ оказался слегка великоват, после четвертой вычитки текста мои глаза меня прокляли.

Что ж, надеюсь, моя работа кому-то пригодится. Приступим.

Содержание

Заметки

Создание Observable

asObservable
create
deferred
empty
error
interval
just
never
of
range
repeatElement
timer

Комбинирование Observable

amb
combineLatest
concat
merge
startWith
switchLatest
withLatestFrom
zip

Фильтрация

distinctUntilChanged
elementAt
filter
ignoreElements
sample
single
skip
skip (duration)
skipUntil
skipWhile
skipWhileWithIndex
take
take (duration)
takeLast
takeUntil
takeWhile
takeWhileWithIndex
debounce

Трансформация

buffer
flatMap
flatMapFirst
flatMapLatest
flatMapWithIndex
map
mapWithIndex
window

Операторы математические и агрегирования

reduce
scan
toArray

Работа с ошибками

catchError
catchErrorJustReturn
retry
retryWhen

Операторы для работы с Connectable Observable

multicast
publish
refCount
replay
replayAll

Вспомогательные методы

debug
do
delaySubscription
observeOn
subscribe
subscribeOn
timeout
using

В схемах я буду использовать обозначение Source/SO в качестве Source Observable, RO/Result в качестве Result Observable.

Функция example просто позволяет отделять вывод в консоли, её код следующий (взят из RxSwift):

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

Также подразумевается, что читатель имеет общее представление о реактивном программировании в общем и об RxSwift в частности. Не знаю, есть ли смысл городить очередную вводную.

Создание Observable

asObservable

Этот метод реализован в классах RxSwift, если они поддерживают конвертацию в Observable. Например: ControlEvent, ControlProperty, Variable, Driver

Консоль:

В данном примере мы Variable преобразовали в Observable и подписались на его события.

create

Этот метод позволяет создавать Observable с нуля, полностью контролируя, какие элементы и когда он будет генерировать.

Консоль:

В данном примере мы создали Observable, который сгенерирует несколько значений, и в конце вызовется complete.

deferred

Этот оператор позволяет отложить создание Observable до момента подписки с помощью subscribe.

Консоль:

В первом случае Observable создается сразу, с помощью Observable.just(i), и изменение значения i уже не влияет на генерируемый этой последовательностью элемент. Во втором же случае мы создаем Observable с помощью deferred и можем поменять значение i перед subscribe.

empty

Пустая последовательность, заканчивающаяся Completed.

Консоль:

error

Создаст последовательность, которая состоит из одного события – Error.

Консоль:

interval

Создает бесконечную последовательность, возрастающую с 0 с шагом 1 с указанной периодичностью.

Консоль:

just

Создает последовательность из любого значения, которая завершается Completed.

Консоль:

never

Пустая последовательность, чьи observer’ы никогда не вызываются, т.е. не будет сгенерировано ни одно событие.

Консоль:

of

Последовательность из переменного количества элементов. После всех элементов генерируется Completed.

Консоль:

В первом случае мы создали последовательность из двух чисел, во втором — из двух Observable, а затем объединили их между собой с помощью оператора merge.

range

Создает последовательность с конечным числом элементов, возрастающую с шагом 1 от указанного значения указанное число раз, после всех элементов генерируется Completed.

Консоль:

Сгенерировались элементы, начиная с 5, 3 раза с шагом 1.

repeatElement

Бесконечно создавать указанный элемент, без задержек. Никогда не будут сгенерированы события Completed или Error.

Консоль:

timer

Бесконечная последовательность, возрастающая с 0 с шагом 1, с указанной периодичностью и возможностью задержки при старте. Никогда не будут сгенерированы события Completed или Error.

Консоль:

В данном примере последовательность начнет генерировать элементы с задержкой в 2 секунды, каждые 3 секунды.

Комбинирование Observable

amb

Из всех Observable SO выбирается тот, который первым начинает генерировать элементы, его элементы и дублируются в RO, остальные SO игнорируются.

Консоль:

Т.к. первым сгенерировал элемент subjectC, лишь его элементы дублируются в RO, остальные игнорируются.

combineLatest

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

Консоль:

В этом примере я создал Observable с помощью timer — для генерации элементов с разной задержкой, чтобы было видно, как перемешиваются элементы. К моменту появления первого элемента sequenceA появилось уже три элемента sequenceB. Поэтому первым элементом в RO последовательности стала пара объектов A0 – B2.

concat

В RO элементы включают сначала все элементы первого Observable, и лишь затем следующего. Это означает, что если первый Observable никогда не сгенерирует Completed, элементы второго никогда не поступят в RO. Ошибка в текущем Observable пробрасывается в RO.

Консоль:

merge

Элементы RO включают элементы из исходных Observable в том порядке, в котором они были выпущены в исходных Observable.

Консоль:

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

startWith

В начало SO добавляются элементы, переданные в качестве аргумента.

Консоль:

switchLatest

Изначально подписываемся на O1 генерируемого SO, его элементы зеркально генерируются в RO. Как только из SO генерируется очередной Observable, элементы предыдущего Observable отбрасываются, т.к. происходит отписка от O1, подписываемся на O2 и так далее. Таким образом в RO — элементы лишь из последнего сгенерированного Observable.

Консоль:

В первом примере показано, как команда работает в статике, когда мы руками переподключаем Observable.
Во втором примере оператором create создан Observable<Observable>, AnyObserver которого мы вынесли в переменную, по таймеру получающую новый Observable, который реализован в виде таймера. Т.к. задержки у таймеров разные, то можно наблюдать. как с помощью switchLatest в RO попадают значения из последнего сгенерированного таймера.

withLatestFrom

Как только O1 генерирует элемент, проверяется, сгенерирован ли хоть один элемент в O2, и если да, то берутся последние элементы из O1 и O2 и используются в качестве аргументов для переданной функции, результат которой генерируется RO в качестве элемента.

Консоль:

zip

Элементы RO представляют собой комбинацию из элементов, сгенерированных исходными Observable, объединение идет по индексу выпущенного элемента.

Консоль:

Из примеров видно, что элементы комбинируются попарно в том порядке, в каком они были сгенерированы в исходных Observable.

Фильтрация

distinctUntilChanged

Пропускаем все повторяющиеся подряд идущие элементы.

Консоль:

Здесь тонкий момент: отбрасываются не уникальные для всей последовательности элементы, а лишь те, которые идут подряд.

elementAt

В RO попадает лишь элемент, выпущенный N по счету.

Консоль:

filter

Отбрасываются все элементы, которые не удовлетворяют заданным условиям.

Консоль:

ignoreElements

Отбрасывает все элементы, передаёт только терминальные сообщения Completed и Error.

Консоль:

sample

При каждом сгенерированном элементе последовательности семплера (воспринимать как таймер) — брать последний выпущенный элемент исходной последовательности и дублировать его в RO, ЕСЛИ он не был сгенерирован ранее.

Консоль:

single

Из исходной последовательности берется единственный элемент, если элементов > 1 — генерировать ошибку. Есть вариант с предикатом.

Консоль:

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

skip

Из SO отбрасываем первые N элементов.

Консоль:

skip (duration)

Из SO отбрасываем первые элементы, которые были сгенерированы в первые N.

Консоль:

skipUntil

Отбрасываем из SO элементы, которые были сгенерированы до начала генерации элементов последовательностью, переданной в качестве параметра.

Консоль:

Генерация элементов в secondSequence была отложена на 1 секунду с помощью команды delaySubscription, таким образом элементы из firstSequence стали дублироваться в RO лишь через 1 секунду.

skipWhile

Отбрасываем из SO элементы до тех пор, пока функция, переданная в качестве параметра, возвращает true.

Консоль:

skipWhileWithIndex

Отбрасываем из SO элементы до тех пор, пока пока функция, переданная в качестве параметра, возвращает true. Отличие от skipWhile в том, что еще одним параметром, переданным в функцию, является индекс сгенерированного элемента.

Консоль:

take

Из SO берутся лишь первые N элементов.

Консоль:

take (duration)

Из SO берутся лишь элементы, сгенерированные в первые N секунд.

Консоль:

takeLast

Из SO берутся лишь последние N элементов. Что означает: если SO никогда не закончит генерировать элементы, в RO не попадет ни одного элемента.

Консоль:

Второй пример приведен для иллюстрации в задержке генерации элементов в RO из-за ожидания завершения генерации элементов в SO.

takeUntil

Из SO берутся элементы, которые были выпущены до начала генерации элементов последовательностью, переданной в качестве параметра.

Консоль:

takeWhile

Из SO берутся элементы до тех пор, пока функция, переданная в качестве параметра, возвращает true.

Консоль:

takeWhileWithIndex

Из SO берутся элементы до тех пор, пока функция, переданная в качестве параметра, возвращает true. Отличие от takeWhile в том, что еще одним параметром, переданным в функцию, является индекс сгенерированного элемента.

Консоль:

debounce

Из SO берутся лишь элементы, после которых не было новых элементов N секунд.

Консоль:

В данном примере элементы генерируются c разными задержками. Поэтому debounce сработает всего несколько раз в момент, когда между элементами будет достаточный временной промежуток.

Трансформация

buffer

Элементы из SO по определенным правилам объединяются в массивы и генерируются в RO. В качестве параметров передаются count (максимальное число элементов в массиве) и timeSpan (время максимального ожидания наполнения текущего массива из элементов SO). Таким образом, элемент RO являет собой массив [T] длиной от 0 до count.

Консоль:

Максимальное число элементов в массиве указано равное трем, и оно никак не влияет на наполнение массива в данном примере. За максимальное время ожидания наполнения таймер успевает сгенерировать не более 2 элементов. Однако период таймера и время ожидания наполнения выбраны таким образом, что третий массив успеет получить лишь один объект.

flatMap

Каждый элемент SO превращается в отдельный Observable, и все элементы из [O1, O2, O3…] объединяются в RO. Порядок генерации элементов в RO зависит от времени их генерации в исходных [O1, O2, O3…] (как в команде merge).

Консоль:

flatMapFirst

Каждый элемент SO превращается в отдельный Observable.
1) Изначально подписываемся на O1, его элементы зеркально генерируются в RO. Пока O1 генерирует элементы, все последующие Observable, сгенерированные из SO, отбрасываются, на них не подписываемся.
2) как только O1 оканчивается, если будет сгенерирован новый Observable, на него подпишутся, и его элементы будут дублироваться в RO.
Повторяем пункт 1, но вместо O1 берем последний сгенерированный Observable.

Консоль:

В примере благодаря задержкам в генерации мы видим, что, пока не произойдет окончание первого Observable, никакой новый Observable его не заменит.

flatMapLatest

Каждый элемент SO превращается в отдельный Observable. Изначально подписываемся на O1, его элементы зеркально генерируются в RO. Как только из SO выпускается очередной элемент и на его основе генерируется очередной Observable, элементы предыдущего Observable отбрасываются, т.к. происходит отписка. Таким образом в RO — элементы из последнего генерированного Observable.

Консоль:

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

flatMapWithIndex

Каждый элемент SO превращается в отдельный Observable, и все элементы из [O1, O2, O3…] объединяются в RO. Порядок генерации элементов в RO зависит от времени их генерации в исходных [O1, O2, O3…] (как в команде merge). Отличие от flatMap в том, что еще одним параметром, переданным в функцию, является индекс сгенерированного элемента.

Консоль:

map

Элементы SO преобразуются, не меняя порядок их генерации. Можно менять не только значение, но и тип элементов.

Консоль:

mapWithIndex

Элементы SO преобразуются, не меняя порядок их генерации. Можно менять не только значение, но и тип элементов. Отличие от map в том, что еще одним параметром, переданным в функцию, является индекс сгенерированного элемента.

Консоль:

window

Элементы из SO по определенным правилам передаются в генерирующиеся новые Observable. В качестве параметров передаются count (максимальное число элементов, которые будут сгенерированы каждым Observable) и timeSpan (время максимального ожидания наполнения текущего Observable из элементов SO). Таким образом элемент RO являет собой Observable, число генерируемых элементов которого равно от 0 до N. Основное отличие от bufffer в том, что элементы SO зеркалятся сгенерированными Observable моментально, а в случае buffer мы вынуждены ждать указанное в качестве параметра максимальное время (если буфер не заполнится раньше).

Консоль:

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

Операторы математические и агрегирования

reduce

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

Консоль:

scan

Каждый элемент SO преобразуется с помощью переданной функции, результат операции генерируется в RO, но, кроме этого, оно передается в качестве параметра в функцию на следующем шаге. В отличии от reduce число элементов в RO равно числу элементов в SO.

Консоль:

toArray

Все элементы из SO после генерации терминального состояния объединяются в массив, и генерируются RO.

Консоль:

Работа с ошибками

catchError

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

Консоль:

После генерации очередного элемента была сгенерирована ошибка, но мы её перехватили и вернули взамен новый Observable.

catchErrorJustReturn

Позволяет перехватить сгенерированную ошибку из SO и заменить её на указанный элемент, после этого SO генерирует Completed.

Консоль:

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

retry

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

Консоль:

Передаваемое в оператор целое число означает количество попыток дождаться успешного окончания. 0 — ни одной попытки, т.е. цепочка ни разу не будет запущена, и просто произойдет completed событие. 1 — такое же поведение, как будто оператор и не не был применен. 2 — исходная попытка + дополнительная, и т.д. Если в оператор не передать параметр, то количество попыток повторить будет бесконечным.

retryWhen

Позволяет перехватить сгенерированную ошибку из SO, и в зависимости от типа ошибки мы либо повторно генерируем ошибку, которая пробрасывается в RO, и на этом выполнение заканчивается, либо генерируем Observable (tryObservable), генерация каждого корректного элемента которого выполнит повторную подписку на SO в надежде, что ошибка исчезнет. Если tryObservable заканчивается ошибкой, она пробрасывается в RO, и на этом выполнение заканчивается.

Консоль:

Я встроил инкремент переменной i в генерацию sequenceWithError, чтобы на 3й попытке ошибка исчезла. Если раскоментировать генерацию ошибки RxError.Overflow, мы её не перехватим в операторе retryWhen и пробросим в RO.

Операторы для работы с Connectable Observable

multicast

Позволяет проксировать элементы из исходной SO на Subject, переданный в качестве параметра. Подписываться нужно именно на этот Subject, генерация элементов Subject начнется после вызова оператора connect.

Консоль:

publish

publish = multicast + replay subject
Позволяет создавать Connectable Observable, которые не генерируют события даже после subscribe. Для старта генерации таким Observable нужно дать команду connect. Это позволяет подписать несколько Observer к одному Observable и начать генерировать элементы одновременно, вне зависимости от того, когда был выполнен subscribe.

Консоль:

Как видно, хоть подписка и была произведена в разное время, пока не вызвали команду connect — генерация элементов не началась. Зато благодаря команде debug видно, что даже после того как все отписались, последовательность продолжила генерировать элементы.

refCount

Позволяет создать обычный Observable из Connectable. После первого вызова subscribe к этому обычному Observable происходит подписка Connectable на SO.
Получается что-то вроде

SO будет продолжать генерировать элементы до тех пор, пока есть хотя бы один подписанный на refCountSequence. Как только все подписки на refCountSequence аннулируются, происходит отписка и publishSequence от SO.

Консоль:

replay

Если SO обычный, — конвертирует его в Connectable. После этого все, кто подпишутся на него после вызова connect(), мгновенно получат в качестве первых элементов последние сгенерированные N элементов. Даже если отпишутся все — Connectable будет продолжать генерировать элементы.

Консоль:

replayAll

Если SO обычный, — конвертирует его в Connectable. Все, кто подпишутся на него, после вызова connect() получат сначала все элементы, которые были сгенерированы ранее. Даже если отпишутся все, Connectable будет продолжать генерировать элементы.

Консоль:

Вспомогательные методы

debug

RO полностью дублирует SO, но логируются все события с временной меткой.

Консоль:

do

RO полностью дублирует SO, но мы встраиваем перехватчик всех событий из жизненного цикла SO.

Консоль:

delaySubscription

Дублирует элементы из SO в RO, но с временной задержкой, указанной в качестве параметра.

Консоль:

observeOn

Указывает, на каком Scheduler должен выполнять свою работу Observer, особенно критично при работе с GUI.

Консоль:

Как видно, благодаря observeOn мы смогли выполнить код внутри subscribe на другом потоке, хотя оба Observable были запущены на background.

subscribe

Оператор, связывающий Observable с Observer, позволяет подписаться на все события из Observable.

Консоль:

subscribeOn

Указывает, на каком Scheduler выполнять подписку на Observable. Редко используемый оператор. Для получения колбэков на нужном Scheduler следует пользоваться observeOn.

Консоль:

timeout

Дублирует элементы из SO в RO, но если в течение указанного времени SO не сгенерировало ни одного элемента, RO генерирует ошибку.

Консоль:

using

using

Позволяет проинструктировать Observable создать ресурс, который будет жить лишь пока жив RO, в качестве параметров передаются 2 фабрики, одна генерирует ресурс, вторая — Observable из ресурса, у которых будет единое время жизни.

Консоль:

Как видно, после того, как Observable закончил генерировать элементы, у нашего ресурса Factory был вызван метод dispose.

За материал выражаем благодарность международной IT-компании Noveo.

Существует два принципиально различных способа организации больших систем: в соответствии с объектами и состояниями, которые живут в системе, и в соответствии с потоками данных, которые проходят через неё. Парадигма реактивного программирования предполагает легкость выражения потоков данных, а также  распространение изменений благодаря этим потокам. Например, в императивном программировании операция присваивания означает конечность результата, тогда как в реактивном значение будет пересчитано при получении новых входных данных. Поток значений проходит в системе ряд трансформаций, которые необходимы для решения определенной задачи. Оперирование потоками позволяет системе быть расширяемой и асинхронной, а правильная реакция на возникающие ошибки – отказоустойчивой.

ReactiveX – библиотека, позволяющая создавать асинхронные и событийно-ориентированные программы, использующие наблюдаемые последовательности. Она расширяет шаблон Наблюдателя для поддержки последовательностей данных, добавляет операторы для их декларативного соединения, избавляя от необходимости заботиться о синхронизации и безопасности потоков, разделяемых структурах данных и неблокирующего I/O.

Одним из основных отличий библиотеки ReactiveX от функционального реактивного программирования является то, что она оперирует не непрерывно изменяющимися, а дискретными значениями, которые “испускаются” в течении длительного времени.

Стоит немного рассказать о том, что такое Observer, Observable, Subject. Модель Observable является источником данных и позволяет обрабатывать потоки асинхронных событий похожим образом с тем, который вы используете для коллекций данных, таких как массивы. И всё это вместо колбэков, а значит, код является более читабельным и менее склонным к ошибкам.

В ReactiveX наблюдатель (Observer) подписывается на Observable и впоследствии реагирует на элемент или последовательность элементов, которые тот отправляет. У каждого Observer, подписанного на Observable, вызывается метод Observer.on_next() на каждый элемент потока данных, после которого может быть вызван как Observer.on_complete(), так и Observer.on_error(). Часто Observable применяется таким образом, что он не начинает отдавать данные до тех пор, пока кто-нибудь не подписывается на него. Это так называемые “ленивые вычисления” – значения вычисляются только тогда, когда в них возникает потребность.

Бывают задачи, для решения которых нужно соединить Observer и Observable, чтобы принимать сообщения о событиях и сообщать о них своим подписчикам. Для этого существует Subject, имеющий, кроме стандартной, ещё несколько реализаций:

• ReplaySubject имеет возможность кэшировать все поступившие в него данные, а при появлении нового подписчика – отдавать всю эту последовательность сначала, работая далее в обычном режиме.
• BehaviorSubject хранит последнее значение, по аналогии с ReplaySubject отдавая его появившемуся подписчику. При создании он получает значение по умолчанию, которое будет получать каждый новый подписчик, если последнего значения еще не было.
• AsyncSubject также хранит последнее значение, но не отдает данные, пока не завершится вся последовательность.

Observable и Observer – только начало ReactiveX. Они не несут в себе всю мощь, которую являют собой операторы,  позволяющие трансформировать, объединять, манипулировать последовательностями элементов, которые отдают Observable.

В документации ReactiveX описание операторов включает в себя использование Marble Diagram. К примеру, вот как эти диаграммы представляют Observable и их трансформации:

Глядя на диаграмму ниже, легко понять, что оператор map трансформирует элементы, отдаваемые Observable, путем применения функции к каждому из них:

Хорошей иллюстрацией возможностей ReactiveX является приложение RSS-агрегатора. Здесь возникает необходимость асинхронной загрузки данных, фильтрации и трансформации значений, поддержания актуального состояния путем периодического обновления.

В этой статье примеры для представления основных принципов ReactiveX написаны с использованием библиотеки rx для языка программирования Python. Вот так, например, выглядит абстрактная реализация наблюдателя:

Наше приложение в режиме реального времени будет обмениваться сообщениями с браузером посредством веб-сокетов. Возможность легко реализовать это предоставляет Tornado.

Работа программы начинается с запуска сервера. При обращении браузера к серверу открывается веб-сокет.

Для обработки введенного пользователем запроса создается Subject, при подписке на который он отправляет значение по умолчанию (в нашем случае — пустую строку), а затем раз в секунду отправляет то, что введено пользователем и удовлетворяет условиям: длина 0 или больше 2, значение изменилось.

Также для периодического обновления новостей предусмотрен Observable, который раз в 60 секунд отдает значение.

Два этих потока соединяются оператором combine_latest , в цепочку встраивается Observable для получения списка новостей. После чего на этот Observable создается подписка, вся цепочка начинает работать только в этот момент.

Следует подробнее остановиться на том, что такое “Observable для получения списка новостей”. Из списка url для получения новостей мы создаем поток данных, элементы которого приходят в функцию, где при помощи HTTP-клиента Tornado AsyncHTTPClient происходит асинхронная загрузка данных для каждого элемента списка urls. Из них также создается поток данных, который фильтруется по запросу, введенному пользователем. Из каждого потока мы берем по 5 новостей, которые приводим к нужному формату для отправки на фронтенд.

После того, как поток выходных данных сформирован, его подписчик начинает поэлементно получать данные. Функция send_response  отправляет полученные значения во фронтенд, который добавляет новость в список.

В файле feeder.js

Таким образом, реализуется push-технология, в которой данные поступают от сервера к фронтенду, который лишь отправляет введенный пользователем запрос для поиска по новостям.

В качестве заключения предлагаю задуматься о том, какая реализация получилась бы при привычном подходе с использованием колбэков вместо Observable, без возможности легко объединить потоки данных, без возможности мгновенной отправки данных потребителю-фронтенду и с необходимостью отслеживать изменения в строке запроса. Среди Python-разработчиков технология пока что практически не распространена, однако я вижу уже несколько возможностей её применить на текущих проектах.

Пример использования ReactiveX для Python вы можете найти в GitHub репозитории с демо-проектом RSS-агрегатора.

Выражаем благодарность Ксении, Python-разработчику компании Noveo, за подробное описание преимуществ реактивного программирования!