Long Lived GRPC Calls

Question

I am wondering the best practice for long lived GRPC calls.

I have a typical Client --> Server call (both golang) and the server processing can take up to about 20-30 seconds to complete. I need the client to wait until it is completed before I move on. Options that I see (and I don't love any of them):

1. Set timeout to absurd length (e.g. 1 min) and just wait. This feels like a hack and also I expect to run into strange behavior in my service mesh with things like this going on.
2. Use a stream - I still need to do option #1 here and it really doen't help me much as my response is really just Unary and a stream doesn't do me much good
3. Polling - (i implemented this and it works but I don't love it) - I do most of the processing async and have my original GRPC call return a transactionID that is stored in Redis and holds the state of the transaction. I created a different GRPC endpoint to poll the status of the transaction in a loop.
4. Queue or Stream (e.g. Kafka Stream) - setup the client to be a listener into something like a Kafka topic and have my server notify the (Queue || Stream) when it is done so that my client would pick it up. I thought this would work but seemed way over-engineered.

Option #3 is working for me but sure feels pretty dirty. I am also 100% dependent on Redis. Given that GRPC is built on HTTP2 then I would think that maybe there is some sort of Server Push option but I am not finding any.

I fear that I am overlooking a simple way to handle this problem.

Thanks

Answer 1

Long-lived gRPC channel is an important use case and fully supported. However, one gRPC channel may have more than one TCP connection, and TCP can get disconnected due to inactivity. You can use keep-alive or HTTP/2 ping to keep TCP alive. See this thread for more details. None of the options you mentioned address the issue that your server takes a while to respond. Unless there’s something I’m missing, nothing in your question is a gRPC issue.