Телеграмм чат группы scala

11:11пожаловаться #1

S

RAFIZ

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

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

потому что 2 независимых стрима требуют 2 независимых источников данных. Если источник данных можно прочитать только 1 раз и нельзя куда-то временно записать, то только так

11:12пожаловаться #2

R

RAFIZ in Scala User Group

потому что 2 независимых стрима требуют 2 независимых источников данных. Если источник данных можно прочитать только 1 раз и нельзя куда-то временно записать, то только так

ну так обычный сорс вроде как раз реюзабл (а про необычные я пока и не знаю в своём изучении стримов)

11:14пожаловаться #3

S

Streams Quickstart Guide • Akka Documentation

RAFIZ

это сэмпл из доки акки

doc.akka.io

Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala.

И все равно он мне не нравится. Я очень много натыкался на проблемы с подобным подходом. Так что я бы использовал GraphDSL.create(writeAuthors, writeHashtags) вместо варианта без параметров. А на самом деле в данном случае обошелся бы без Graph DSL - используя Sink.combine

11:17пожаловаться #4

S

RAFIZ

ну так обычный сорс вроде как раз реюзабл (а про необычные я пока и не знаю в своём изучении стримов)

Пример не реюзабла: HttpRequest.

11:17пожаловаться #5

R

RAFIZ in Scala User Group

И все равно он мне не нравится. Я очень много натыкался на проблемы с подобным подходом. Так что я бы использовал GraphDSL.create(writeAuthors, writeHashtags) вместо варианта без параметров. А на самом деле в данном случае обошелся бы без Graph DSL - используя Sink.combine

вот да, про Sink.combine интересно

11:17пожаловаться #6

S

Еще не реюзабл: любой SourceRef

11:18пожаловаться #7

R

RAFIZ in Scala User Group

Пример не реюзабла: HttpRequest.

точно
спасибо.

11:19пожаловаться #8

S

Стрим, получаемый из любой БД как бы реюзабл, но зачем делать 2 запроса вместо одного? Это не всегда оправданно

11:19пожаловаться #9

R

RAFIZ in Scala User Group

в этой ситуации не стоит/нельзя вывернуться созданием Source обычного на основе как раз такого HttpRequest?

или тут и нужно использовать те подходы о которых и речь как раз?броадкастинг, combine

11:20пожаловаться #10

R

RAFIZ in Scala User Group

Стрим, получаемый из любой БД как бы реюзабл, но зачем делать 2 запроса вместо одного? Это не всегда оправданно

👍🏾

11:21пожаловаться #11

Oℕ

Oleg ℕizhnik in Scala User Group

RAFIZ

в этой ситуации не стоит/нельзя вывернуться созданием Source обычного на основе как раз такого HttpRequest?

или тут и нужно использовать те подходы о которых и речь как раз?броадкастинг, combine

Это как вы предлагаете вывернуться?

11:21пожаловаться #12

Oℕ

Oleg ℕizhnik in Scala User Group

Вычитать всё тело? Тогда он начнёт обрабатываться позже, и будет каждый раз больше оперативы кушать

11:22пожаловаться #13

Oℕ

Oleg ℕizhnik in Scala User Group

А есть принципиально бесконечные горячие источники данных