Hi White,
1. Is it possible that you abstract and implement your actual calls outside the grpc framework. You can still use protobuf to organize your calls, instead of defining a lot of grpc methods, you define only one async grpc method streaming on both sides. In the streamed message, you can have something similar as below. Then after running the method, you return the uuid with the any method_reply. I just happen to pop up this idea and maybe it is more complicated in your case. Anyway, we can try to use more protobuf but should not heavily tie to async grpc methods. grpc async methods are not so easy to use, especially combined with streaming. I do not see any example or detailed documentation, tricky to handle it correctly. I sometimes questioned that grpc is widely used inside Google. 2. You can check this version simplified call data <https://github.com/weidonglian/grpc-playground/blob/master/greeter_async_server.cc>, see if helps a bit. I think it is possible that you can wrapper async methods inside your own defined AsyncServiceImpl, but I do not think it will be as elegant as the synced service. I am also interested to see how the googlers handle these issues in their own products. Thanks, Weidong message Command{ string uuid; EnumService service; EnumMethod method; any method_request; } In the server side, you unpack the message which includes all the information to make the actual calling. It adds an extra layer to run the actual call outside of the grpc framework. Yes, it adds a bit extra complexity, but your implementation is less dependent of grpc, you can even switch to socket/websocket easily. On Friday, March 16, 2018 at 11:13:02 AM UTC+1, White Sword wrote: > > My team is designing a scalable solution with micro-services architecture > and planning to use gRPC as the transport communication between layers. And > we've decided to use async grpc model. The design that example( > greeter_async_server.cc > <https://github.com/grpc/grpc/blob/master/examples/cpp/helloworld/greeter_async_server.cc>) > > provides doesn't seem viable if I scale the number of RPC methods, because > then I'll have to create a new class for every RPC method, and create their > objects in `HandleRpcs()` like this Pastebin > <https://pastebin.com/PSJs3sqV> (complete code). > > > void HandleRpcs() { > new CallDataForRPC1(&service_, cq_.get()); > new CallDataForRPC2(&service_, cq_.get()); > new CallDataForRPC3(&service, cq_.get()); > // so on... > } > > > > It'll be hard-coded, all the flexibility will be lost. > > I've around 300-400RPC methods to implement and having 300-400 classes > will be cumbersome and inefficient when I'll have to handle >100K RPC > requests/sec and this solution is a very bad design. I can't bear the > overhead of creation of objects this way on every single request. Can > somebody kindly provide me a workaround for this. Can async grpc c++ not be > simple like its sync companion? > > TIA > -- 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/44622fc1-1f29-420a-aed3-b04c33f34145%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
