Чем отличается использование перечислителей, итераций и перечислителей Play Frameworks с использованием RxScalas Observables, подписок и т. Д. Для асинхронных потоков данных?
В каком типе сценариев вы бы выбрали RxScala и когда выбрали бы Play?
Если бы через ваш поток проходили большие объемы данных, повлияло бы это на ваше решение?
Все зависит от того, что вы хотите делать. Итеративы великолепны, если вы хотите выполнить синтаксический анализ в стиле комбинатора. Они действительно просты - у них есть один метод, называемый fold, все остальное в итерациях, перечислителях и перечислителях - это просто вещи, которые вызывают fold. Но для многих этот функциональный подход к потоковой обработке - слишком много умственных вложений, чтобы их изучить, поэтому более императивные подходы, такие как RX, могут быть более подходящими. Именно по этой причине сама игра перемещается в потоки Akka.
Вопрос интересен, потому что в нем сравниваются два совершенно разных способа сделать одно и то же. Я изучал различия этих библиотек в проекте с Мартином Одерски из EPFL.
Обратите внимание, что эта работа была проделана до того, как Play переместится на потоки Akka, поэтому Джеймс Ропер ответил хорошо, когда мы смотрим на настоящее и будущее. Однако, поскольку вы действительно спрашиваете о различиях между ними, я могу попытаться дать некоторое представление здесь.
С Rx легко работать, если вы знакомы с объектно-ориентированным программированием (что в большинстве случаев так и есть). Итерации воспроизведения происходят из чисто функционального мира (см. Haskell Enumerator и Iteratee) и менее интуитивно понятны. Таким образом, написание одного и того же приложения сильно отличается. Однако сопоставление между Iteratees и Observables может быть выполнено (см. Ссылку GitHub ниже). Но у этого есть предел.
Основная проблема, которую мы можем определить, заключается в том, что Iteratees изначально поддерживают обратное давление, а Observables - нет. Действительно, если поток данных слишком велик, Rx будет хранить данные в объекте (то есть в стеке). В этом контексте это может быстро привести к проблемам с памятью. Однако, поскольку Iteratees чисто функциональны, каждая часть данных будет потребляться функцией в операции сворачивания. В этом смысле второй элемент не может быть передан Iteratee, если первый еще не потреблен (функция все еще не существует!). Это то, что мы называем обратным давлением, потому что производитель данных имеет представление о скорости потребителя, и проблема скорости потока передается обратно производителю данных.
В заключение, если вам абсолютно комфортно работать с обеими библиотеками и вы хотите выбирать между ними, вы можете подумать о назначении приложений. Если у вас никогда не будет больших потоков, вы можете использовать Rx. В противном случае я бы рекомендовал использовать Iteratees.
Было бы интересно узнать об обратном давлении в Akka Streams. Изначально, поскольку это библиотека передачи сообщений, проблема должна быть такой же, как и с Rx. Однако, похоже, есть интересная работа в этой области, например статья, позволяющая обойти проблему с использованием TCP.
Взгляните на GitHub или полный текст здесь: Observables for Play!
Subscriber.request. См., Например, вики страница.
- person Samuel Gruetter; 22.07.2015
