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/0d5943f3-669b-48db-a23b-130c775bf373%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
