Problem with the design of the async grpc model

[qgrav...@gmail.com]

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) 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 (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

[Vijay Pai]

Thanks for raising this issue. We currently don't have any solution for this since each method type needs to be requested separately at an async service. It seems like it would be a useful add-on but we have no API-level approach for this.

[Weidong Lian]

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.

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. 

[White Sword]

thanks for the solution buddy. Due to project deadlines, I had to go on with the sync version, I've also implemented a very simple templated version of it which needs improvements. I will post it in here in free time.