Perfect !!! Thanks Srini for clarifying.
Said that, I would like to clarify a couple of points for particular
client i.e., * gRPC-web*
As we know, gRPC-web has gone through GA release. So we can now count on
it.
As we know, grpc-web is the java-script library for making grpc requests
from browser.
If I want to make true gRPC end-to-end from browser to the service (without
any http1.1 conversion through proxy), I believe I can do that.
When we accomplish that and invoke some gRPC service for eg., echoService =
new EchoServiceClient('http://localhost:8080') ,
*my understanding is there is NO XHR or FETCH involved in this
communication. Basically we are not talking about any AJAX here. Am I
correct ?*
And secondly,
As we know, JS is not a statically typed language. (unlike java or C++)
so when I use above stub to invoke the gRPC server running on port 8080
for eg.,
var echoService = new EchoServiceClient('http://localhost:8080');var request =
new EchoRequest();request.setMessage('Hello World!');echoService.echo(request,
{}, function(err, response) {
// ...});
*Does any kind of type checking happen by the underneath gRPC client JS
library i.e., "google-protobuf 3.6.1" OR "grpc-web 0.4.0" ?*
Appreciate your help !!!!
Thanks.
On Friday, April 5, 2019 at 3:50:58 PM UTC-5, Srini Polavarapu wrote:
>
> Your understanding is correct. You may want to consider using streaming
> instead of repeated field if the aggregate response size is very large
> which can cause out-of-memory or flow control issues in your application.
> Using unary for large repeated response has no big benefits over streaming.
> Even in the case of large unary response, the HTTP/2 transport will break
> it up into smaller frames and stream it to the client. It is assembled back
> into a single response before presenting it to the application.
>
> In gRPC, client always initiates the RPC which translates to client always
> initiating the stream.
>
> On Friday, April 5, 2019 at 12:44:46 PM UTC-7, chirag shah wrote:
>>
>> 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/3f484652-e5e7-4e0d-a890-83a46198f34f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
