Why there isn't Flow for streams?
davidbilik opened this issue · comments
Hello, great library! I have a question if using of Flow instead of Channels is considered in the future. As far as I understand its more suitable since it supports cold streams. Also lot of operators on Channels are deprecated in favor of Flow.
Thats a great question. The choice to stick with channels over flows is mostly driven by this blog post Cold flows, hot channels. Streaming rpcs are backed by an underlying network connection and external producer. They are considered hot by nature.
From the article.
There is a coroutine on the other side of the channel that is working to produce the values, so we cannot just drop a reference to the ReceiveChannel
This statement holds true for gRPC coroutines. The only difference being that the coroutine on the other side is across a network boundary.
When you invoke a streaming rpc, the corresponding receiver (which can be a client, server or both) is receiving messages produced by an external resource which it does not have explicit control over. The invocation itself immediately binds the call to a single backend.
Just like a sequence, a flow represents a cold stream of values. Caller of foo gets a reference to the flow instance, but the code inside flow { ... } builder is not active, no resources are bound to it yet.
My understanding of flows is that they are meant to be used to represent reusable suspending pipelines. I do know there has been effort to refactor the underlying machinery for channels to flows as to improve their performance. The same can probably be said about kroto-plus-coroutines. At the moment there are some internals related to back pressure management that might benefit from flows. But as for the API exposed to users I still think channels are a more natural fit.
I think there is still work to be done on stabilizing the channels API in coroutines that was reliant on the release of flows. This work will likely introduce replacements to certain deprecated APIs. Since both APIs are still evolving I'm reluctant to make any major changes at the moment. That said, this doesnt leave out the possibility of major changes in the future.
David,
Thank you for raising this question.
Marco,
Thank you for the analysis. And for explaining.
Great clarification about channels, I am intrigued by the backpressure you mentioned, Can this be a motivation to add support for flow, similar to reactive-grpc, where a stream to stream takes in flow as a request and sends a flow as response, and the backpressure is handled by windows at the lower level and in memory buffer at the higher level ?