I think I found some clarification which is like...
In general, if your use case would allow the client to process the incoming
messages one at a time, the stream is the better choice.
If your client will just be blocking until all of the messages arrive and
then processing them in aggregate, the repeated field may be appropriate.
So looks like both the approaches are correct.
In that case, in the gRPC no matter which kind of streaming we are doing
(i.e., client-side, server-side or bidirectional) my understanding is
the HTTP/2 stream that gets created underneath is always initiated by the
client. Server is not creating the HTTP/2 stream.
Am I correct ?
Thanks.
On Friday, April 5, 2019 at 1:38:06 PM UTC-5, chirag shah wrote:
>
> Hello ,
>
>
> In gRPC we have 4 typical ways of client-server communication. Let’s pick
> server-streaming.
>
> As we know Server streaming meaning a single client request triggers
> multiple response from the server. I wanted to zoom into this line.
>
> Let’s say following is one such method in the service of my
> protocol-buffer file.
>
> *rpc ListFeatures(Rectangle) returns (stream Feature)*
>
>
>
> This method obtains the Features available within the given Rectangle.
>
> Results are streamed rather than returned at once (e.g. in a response
> message with a repeated field), as the rectangle may have huge number of
> features.
>
> But that is exactly what I am not following.
>
> Just because server wants to send more than one Feature object, that
> should not be a qualification for using Stream (I can do it with Unary call
> too)
>
> If server wants to send multiple feature objects, in my proto-buffer
> file, I can create a wrapper message object like
>
> message FeatureResponse {
>
> repeated Feature features = 1;
>
> }
>
>
>
> message Feature {
>
> string url = 1;
>
> string title = 2;
>
> }
>
>
>
> And now server can expose *rpc ListFeatures(Rectangle) returns
> (FeatureResponse) This is Unary call.*
>
>
>
>
>
> My understanding about using Server-side-Streaming RPC call is *when the
> server does not have all the complete data right when the RPC call came
> from the client (Or expecting more and more data along with the time)*
>
> So when client call method *ListFeatures*, server prepares
> FeatureResponse and stuff as many Features as possible at that point of
> time and push it out to the client on the HTTP2 stream initiated by the
> client.
>
> It however, knows that after some time (for eg., 15 min) he is going to
> get another set of Features object to send out.
>
> So that time it will use the SAME logical HTTP2 stream to push out those
> new objects.
>
>
>
> Am I correct ? If not how can we realize above business situation where
> server for eg., has to push out the latest stock prices every 30 min .
>
>
>
> Really appreciate your help demystifying this concept.
>
>
>
> Thanks.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/aa4e7721-dc26-4816-9420-5bd55bd465ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
