Durable queue

[j...@emailline.net]

Currently I'm using rabbitmq and I'd prefer standardizing on gRPC, but I don't have a mechanism to "send and forget" with durable delivery.

Is there a common practice on a using a durable queue in golang with gRPC?

- James

[Doug Fawley]

gRPC itself is a transmission protocol, not a message queue/pubsub system.  You would need a database or other external service (like rabbitmq or redis) to store your unprocessed messages.

Common practice to do this in gRPC servers is to accept an RPC, publish/store the request, then return from the RPC and process the message asynchronously with background workers.  This makes the RPC itself fast and guarantees no message loss.  Where results are needed by the client, the RPC would return a tracking token or send results asynchronously through another channel.

This has a few benefits over having your clients go directly to your database/messaging system to send requests, e.g. you can change it in the future transparently to your users.

Thanks,

Doug