I want to use GRPC in a C++ application where the client sends out rpc mainly triggered on user events. These calls all return google.protobuf.Empty so I'm not interested in any return value on the client side.
Google suggests to use the async API when possible in C++. Now in my scenario, where the completion of the call is not handled on the client side anyway, I wonder if I'd still go for the async API in order to gain performance. In that case, I should probably set up some kind of low priority "garbage collector" thread that calls CompletionQueue::Next and then does nothing, just to ensure that the queue does not grow unlimited. Still this seems a bit like an overkill. At best there would be a dummy completion queue variant that just drops the event on completion itself, but I'm not aware of anything like that.
I don't have a real idea on how performant or imperformant using the sync API would be in my case. Is there any best practice guidance for this scenario?
Even though the response is empty, sync call will still wait for connection establishment, network delays, completing processing of the call on the server.
If your client side is okay being blocked for that time (also remember the tail latency, we should not expect every call complete in about same time) then maybe use sync api.