What about streaming API

[Monnoroch]

So, what if my service has several usual RPC methods, which you do support, but also has a streaming methods, in which you basically subscribe to some events and then the service pushes them to you until you unsubscribe.
Is there any way to model it in go-kit right now? And if it isn't, then is support for it planned?

[peterbourgon]

No, and tentative yes, respectively.

To give you some idea of my thinking: we can build a streaming endpoint.Endpoint. What would the general form look like? What value-add packages would make sense to layer in as middlewares? I don't have good answers to these questions right now.

[alimoeeny]

I actually need this too, I was thinking of using websockets and keeping the handler from returning until I either get disconnected or otherwise decide to exit.

[peterbourgon]

(In case it wasn't obvious, I'd be very happy to hear proposals for my questions, above.)

[Monnoroch]

Well, yes, I guess you could treat it like a very long RPC call that returns binary stream. With that in mind, simple websocket transport would solve the problem, since you can for instance return a channel from the service and then just loop over it and dump jsons to websocket.
This way, websocket isn't a bidirectional messaging protocol, but rather just like a big http response which can be split to form stream of objects.

[peterbourgon]

@Monnoroch Is that how you model it in your org, generally speaking? I'm dubious that's the correct way to think about it, but I don't really know. Instrumentation would need to happen differently. The circuitbreaker and ratelimit packages still work in a sense, but you probably want a different class of middleware altogether, like throttlers, which can only work if the endpoint definition exposes io.Reader/io.Writer as first-order concepts. And does it make sense to include context.Context—I guess so?

[peterbourgon]

Related: https://github.com/micro/go-micro/blob/master/client/rpc_stream.go

[Monnoroch]

@peterbourgon My feeling is that frameworks do not yet support streaming good enough, so I personally handle streaming in a unique per case basis without much generalization, that's why I asked the question, otherwise I'd just made a pull request.
Also, I kind of don't like the idea of channels here, since they add unnecessary burden of goroutines and synchronization, and prefer a push-based stream interface.
On the other hand, I'm also thinking of even crazier idea of a RPC which takes streams as arguments and gives streams as results: this would be really useful to model some IoT applications I'm thinking about, like converting stream of detector events to a stream of decisions which can obviously be done by just making lots of RPCs, but not quite, if this RPC has to have a state, like calculating moving average for a stream of numbers.
Anyway, these are just thoughts so far, just thought would be cool to be able to implement those as nicely as usual RPC APIs.

[peterbourgon]

I agree that channels probably aren't the right way to model a streaming API. I'd love for someone to contribute a basic Reader/Writer-oriented streaming API endpoint signature so we can iterate on the value-add stuff we'd build around it.

[peterbourgon]

I'd like to move discussion to #295. Thanks for filing the issue!

[IvalisEXE]

I have the same problem, is there a good answer for using regular grpc services and stream with go-kit

[einouqo]

Hi @peterbourgon and go-kit contributors,

I've found great utility in go-kit for my projects, but I also needed to work with gRPC streams. To address this, I put together some code which might be useful to others in the go-kit community.

In the project, ext-kit, you'll find server-side, client-side and bi-directional implementations for gRPC streams, designed with the core concepts of go-kit in mind. There's also a WebSocket transport layer implemented.

You can check it out here: ext-kit

I'd appreciate any thoughts or feedback on this approach. If it makes sense, and with your guidance, I'd be interested in working to create a PR to bring these into go-kit. I realize the use of generics may be a stumbling block, so I'm prepared to refactor for compatibility with go1.17.

Thank you for your time.

[peterbourgon]

Go kit is effectively feature-frozen, so new capabilities like you're describing are highly unlikely to be merged in.