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 <[email protected] > <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/9dd7010a-d67d-48db-855d-ee958c7e193d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
