Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why there isn't Flow for streams? #54

Open
davidbilik opened this issue Jun 20, 2019 · 3 comments
Open

Why there isn't Flow for streams? #54

davidbilik opened this issue Jun 20, 2019 · 3 comments

Comments

@davidbilik
Copy link

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.

@marcoferrer
Copy link
Owner

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.

@peter-lyons-kehl
Copy link

David,
Thank you for raising this question.

Marco,
Thank you for the analysis. And for explaining.

@marcoferrer marcoferrer pinned this issue Aug 2, 2019
@abdulkaderjeelani
Copy link

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants