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 
   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.


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?

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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to