Okay great, thanks!

That's helped to clear it up quite a bit for me. Is there a particular 
reason to avoid sending each RPC call in its own thread?

On Friday, September 25, 2020 at 8:24:23 PM UTC+2 Eric Anderson wrote:

> On Mon, Sep 21, 2020 at 5:54 AM Nicholas Bunn <[email protected]> 
> wrote:
>
>> What I am looking for is a way to query all four services in parallel and 
>> wait for a callback or notification from each one once they have completed 
>> their process, and their information is available. Would one be able to 
>> achieve this with streaming? Or is the client still limited to 
>> communication with one server at a time (essentially implementing a 
>> blocking call)?
>>
>
> Unary vs streaming and blocking vs async (or non-blocking) are separate 
> dimensions. Unary vs streaming is talking about the actual semantic 
> structure while blocking vs async is a detail about the *API*. So 
> blocking vs async is really a question of "how have gRPC implementations 
> exposed these RPCs."
>
> A large number of gRPC language APIs support 
> don't-consume-a-thread-per-RPC. Go uses blocking, but goroutines avoid your 
> concern. Java has a Future API for unary and an async API for unary and 
> streaming. Kotlin supports coroutines. C# supports async/await, although 
> I'm not as familiar with the streaming API. Node.js is (obviously) async. 
> Python now supports async/await. C++ has an async API, although it is 
> pretty different than what you may be used to (and IIRC the callback API 
> isn't quite ready yet). And there's other implementations as well.
>
> So you are pretty free to take your pick. If you are leading toward Java 
> already, using unary RPCs and Futures is probably easiest. You can use 
> something like Guava's Futures.allAsList() 
> <https://guava.dev/releases/snapshot/api/docs/com/google/common/util/concurrent/Futures.html#allAsList-com.google.common.util.concurrent.ListenableFuture...->
>  
> to combine the results and cancel the other RPCs if any one of the RPCs 
> fails. There's many other ways to mix-and-match. Streaming is certainly 
> possible as well, but there's fewer utilities to combine the results so you 
> may have more boilerplate.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/e38216f3-78c8-47be-832b-83662f435016n%40googlegroups.com.

Reply via email to