You say micro-services and then say your server will have 300-400 rpcs? Are they part of the same service or many independent services and you are just trying to get a common framework together?
I had a similar problem in my application which is/was largely a monolith and I had to add gRPC support to it. The async example seems more of a simple to understand (a bit odd however until you get familiar with async model) code that can be used to implement a service with few rpcs. Anyhow, I posted my working code at https://groups.google.com/forum/#!topic/grpc-io/T9u2TejYVTc (and in some other posts) for this particular problem. You can check it out. I was helped by the fact that my application had a code generator (different from grpc code generator) where I could plug-in and generate all of the "request rpc" calls. When my server starts up, it automatically makes those "request rpc" calls for each rpc without every service writer needing to make/add the call. If you don't have a code generator already, you could probably write a custom code generator plugin for Protoc (much like grpc code generator) and can automate this stuff. Hope that helps. Arpit On Friday, March 16, 2018 at 3:13:02 AM UTC-7, qgrav...@gmail.com 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/0e469a44-aba9-407b-9dea-12f89f9acf28%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
