[grpc-io] Re: Problem with the design of the async grpc model

2018-04-13 Thread 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. 

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 
> )
>  
> 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(_, cq_.get());
> new CallDataForRPC2(_, cq_.get());
> new CallDataForRPC3(, 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.

[grpc-io] Re: Problem with the design of the async grpc model

2018-04-12 Thread 'Vijay Pai' via grpc.io 
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.

On Friday, March 16, 2018 at 3:13:02 AM UTC-7, 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 
> )
>  
> 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(_, cq_.get());
> new CallDataForRPC2(_, cq_.get());
> new CallDataForRPC3(, 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/5e304122-e938-42cb-8b0f-f9a5e6d77640%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Problem with the design of the async grpc model

2018-03-28 Thread Arpit Baldeva 
Check out the example I added 
at https://groups.google.com/forum/#!topic/grpc-io/T9u2TejYVTc 

As for 300-400 rpcs, you can write a custom code generator that plugs in to 
ProtoC (much like grpc_cpp_plugin) and have it generate additional code 
that you may need (like auto "requesting" your server to enable these rpcs 
at the start up). I have similar sort of set up. I did not write the code 
generator plugin I suggest here because my application already had one 
(grpc support was an addition).

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 
> )
>  
> 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(_, cq_.get());
> new CallDataForRPC2(_, cq_.get());
> new CallDataForRPC3(, 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/fe4607d9-1606-461d-a7a4-de79ee259a76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Problem with the design of the async grpc model

2018-03-28 Thread Arpit Baldeva 
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 
> )
>  
> 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(_, cq_.get());
> new CallDataForRPC2(_, cq_.get());
> new CallDataForRPC3(, 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.