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 On Monday, May 29, 2017 at 9:55:03 PM UTC-7, [email protected] wrote: > > 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 > -- 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/908fe779-e739-4df0-9174-c05d590cad6e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
