WebSocket Akka HTTP на практике

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

Спасибо за статью, прям актуально.
Побольше бы статей про Akka и Streams в частности. Недавно с ними разбирался, с ходу не зашло. Но после пары статей с примерами все встало на свои места.
В принципе streams позволяет представить весь data flow как некоторый поток, где и просто преобразования, и запросы по сети, и теже акторы спокойно интегрированы. Новый источник, не проблема Source — map — merge и в общий котел, надо отправить еще кроме email sms: %flow% — broadcast(2) — Sink. Красота. Ну и главный плюс back pressure из коробки.

Хочу сказать, что ставить GraphStage на один уровень с Sink и Source — это примерно как говорить, что у нас есть Map, Set и LinkedList. Утверждение корректное, но Sink и Source — это интерфейсы, обозначающие конец и начало стрима, а GraphStage — это конкретная реализация стримов произвольной формы (GraphStage может иметь форму Sink'ов, Source'ов, Flow'ов, BidiFlow'ов и прочего).

Основные интерфейсы в Akka Streams это Source, Flow и Sink:

Linear processing pipelines can be expressed in Akka Streams using the following core abstractions:

Source: A processing stage with exactly one output, emitting data elements whenever downstream processing stages are ready to receive them.

Sink: A processing stage with exactly one input, requesting and accepting data elements possibly slowing down the upstream producer of elements

Flow: A processing stage which has exactly one input and output, which connects its up- and downstreams by transforming the data elements flowing through it.

RunnableGraph: A Flow that has both ends "attached" to a Source and Sink respectively, and is ready to be run().

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

У вас есть небольшая недоработка.
Если сообщение будет большим, то оно просто потеряется.
Недостаточно

case TextMessage.Strict(t) ⇒ 

еще надо добавить обработку

case TextMessage.Streamed(stream) ⇒ 

Например так

case TextMessage.Streamed(stream) ⇒ stream.runFold("")(_ + _)