Yes indeed, from streaming purposes such as video that would not be possible at the moment. This first release was thought for streaming applications with 1-to-1 mapping of request-responses, in order to take advantage of the open connection and the low bandwidth comparing to a classic http connection. In my company it has become a very useful asset. I am already thinking on another implementation of this "promise/functional_programing" method for real streaming communications, in order to avoid listening to 'data' events. If you have any ideas in mind, would you let me know? I'll keep you posted as soon as something new comes up.
Le mer. 3 mai 2017 à 20:33, Michael Lumish <[email protected]> a écrit : > I think this is an interesting library, but I had a couple of concerns > about the API, particularly regarding streaming requests. First, I noticed > that in your server streaming example, the response messages appear to be > coalesced into an array before being returned to the user, which seems to > negate two major advantages that would lead someone to use streaming > responses in the first place: providing the ability to handle responses as > they are generated by the server, and avoiding the need to keep all > responses in memory simultaneously. For example, one use of streaming > responses could be for video streaming, where each response is a small > chunk of video data. Holding all of the data until the end of the call > would essentially turn a video stream into a video download. > > I also noticed that the bidirectional streaming section had this caveat: > "In order to keep track of the messages sent and to be able to callback all > the requests, the server implementation needs to answer with the same id > received". This makes it sound like your API only supports bidirectional > streams with a 1-to-1 mapping of requests to responses, which would be a > major restriction of general bidirectional streaming semantics. Does that > mean that your bidirectional streaming API requires request and response > messages to contain an integer id field, and that that id field is only > used to store the message sequence number within a single stream? > > On Wed, May 3, 2017 at 4:50 AM 'Carles Sistaré' via grpc.io < > [email protected]> wrote: > >> My pleasure to introduce you this new npm module for promisifying all >> client requests in Node >> https://www.npmjs.com/package/grpc-promise >> https://github.com/carlessistare/grpc-promise >> >> Cheers >> >> -- >> > 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/9581baae-f9c0-434c-9cd7-713bf4844ebc%40googlegroups.com >> <https://groups.google.com/d/msgid/grpc-io/9581baae-f9c0-434c-9cd7-713bf4844ebc%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/CADrHRYKmaSs4_bqMp-KCAXb5sRGKOGuM2EwR_rDFPsFWa0rv5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
