On Mon, Apr 8, 2019 at 7:03 AM chirag shah <[email protected]> wrote:
> 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 ?*
>
I am not sure if I get the question completely, but
- when you just called `new` on the client, there is no XHR or FETCH call
associated with just calling the constructor
- when you call echoService.echo(request, ....), underneath, as an
implementation details that might change in the future, it becomes a XHR
request.
>
> 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" ?*
>
>
I believe there are some rudimentary type-checking at runtime for the
google-protobuf package. For grpc-web, there is an option to write
TypeScript on top of the generated client and there you can have
develop-time type checking. Please see the Github repo for more information.
>
> 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
> <https://groups.google.com/d/msgid/grpc-io/3f484652-e5e7-4e0d-a890-83a46198f34f%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CAEteGX0uT3VG_R-E%3DfEBE7AxHTbn2tke_U7p%2BY3d%3DaqSa%2B49_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
