Re: [grpc-io] Re: server side streaming
Thanks Stanley. Your response definitely makes sense to me. I did find
Typescript plugins that will emit out .d.ts files.
On Wednesday, April 10, 2019 at 12:55:45 PM UTC-5, Stanley Cheung wrote:
>
>
>
> On Mon, Apr 8, 2019 at 7:03 AM chirag shah > 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)
>
> I
Re: [grpc-io] Re: server side streaming
On Mon, Apr 8, 2019 at 7:03 AM chirag shah 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;
[grpc-io] Re: server side streaming
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 wil
[grpc-io] Re: server side streaming
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 grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
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/2402699e-19ec-440b-ac10-a451ba0ed1f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[grpc-io] Re: server side streaming
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 grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
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.
