fluid zealot
In the Basics tutorial, ListFeatures() here https://grpc.io/docs/languages/go/basics/#defining-the-service takes a Rectangle and returns a Feature stream - this makes sense to me so far.
Given the above, my question is this: how come in the serverside definition of ListFeatures() here https://grpc.io/docs/languages/go/basics/#server-side-streaming-rpc the stream is now an argument to the method and not its return type?
[BEGINNER] gRPC stream arguments
blissful lintel
which one are you specifying
rpc ListFeatures(Rectangle) returns (stream Feature) {}
wouldnt this be the correct one?
it defines ListFeatures taking a tectangle, and returning a stream of feature
fluid zealot
Hi @blissful lintel, I'm just going through that tutorial and not understanding why the serverside definition of the method itself takes the stream as an argument rather than returns it. I just don't get it.
Ah I had the wrong link for the second bit, just fixed it, should be https://grpc.io/docs/languages/go/basics/#server-side-streaming-rpc
blissful lintel
the link you posted now make more sense
fluid zealot
Does that make my question clearer? I just don't understand why the implementation's method signature is like that
blissful lintel
yep i was confused what you meant by taking a stream but now i see what you mean
fluid zealot
Sorry!
blissful lintel
func (s *routeGuideServer) ListFeatures(rect *pb.Rectangle, stream pb.RouteGuide_ListFeaturesServer) error {
for _, feature := range s.savedFeatures {
if inRange(feature.Location, rect) {
if err := stream.Send(feature); err != nil {
return err
}
}
}
return nil
}
```basically imagine stream is kinda like a response writer
it's the thing you use to "send stuff" to the client who is listening to the stream
you call stream.Send() to send something to the other endOh, does it take the stream as an arg and it's implicitly a pointer?
blissful lintel
in the guide the variable is named as "stream"
but reality it's just something your code can use to write to the client's stream
the designers probably figured this is the best way to do a streaming return
fluid zealot
I'm going to do some experimentation, I think I'm sort of getting it but just not that mismatch when the example unary definition isn't like that and makes more sense
Thanks for your help, @blissful lintel, I'll have a play with it
blissful lintel
Oh, does it take the stream as an arg and it's implicitly a pointer?
i dont have actual interaction with grpc, but if pb.RouteGuide_ListFeaturesServer is an interface, it's implicitly a pointer
if it's a struct instead, maybe the important stuff in it is a pointer
fluid zealot
This one makes more sense, the unary example https://grpc.io/docs/languages/go/basics/#simple-rpc
Takes a Point, returns a Feature
Which matches
// Obtains the feature at a given position.
rpc GetFeature(Point) returns (Feature) {}
in this context it's a single return
in golang you cant do continuous return/generators
so you have to get creative to achieve that
so you would need to pass something like a channel to the function
so the function can keep "giving" new values without terminating itself
fluid zealot
Understood - and the protoc compiler understands that stream is a special case?
blissful lintel
assumed so, therefore it instead have a special argument which you can use to "feed" data into the client
func (s *routeGuideServer) ListFeatures(rect *pb.Rectangle, stream pb.RouteGuide_ListFeaturesServer) error { instead of normal generation, it adds a new argument
if err := stream.Send(feature); err != nil { and it can be used like this
fluid zealot
OK thanks, I get it now 🙂