0

I have a handful of gRPC servers, and would like to chain some of the calls, so that the flow would become something like:

Client X calls Server A
  └──> Server A
           ... some processing ... < 1 >
           calls Server B
             └──> Server B
                      ... some processing ...
                      returns Result B
           receives Result B
           ... some more processing ...
           returns Result A

For this to work, I have been creating a gRPC client for Server B connection at each time Server A RPC gets called (shown with < 1 > above). I found a similar question asked here, and I understand this approach doesn't fit with the long lived connection to make use of concurrency nature discussed here.

What I didn't quite get from the above two references is when I should be creating the gRPC client. If I were to chain this even further with Server B calling Server C, etc., does each server need to generate the connection at the process start time? Does that introduce start-up dependency of each server?

Also, as a baseline, I thought using the context allows nice chaining and still keep control of those remote calls. Is this a correct usage of gPRC?

Ryota
  • 1,157
  • 2
  • 11
  • 27

1 Answers1

1

We've improved the GoDoc for ClientConn. See: https://github.com/grpc/grpc-go/pull/3096.

Let us know what you think. Thanks.

  • Thanks very much for this clarification and enhancement, Easwar! I have played with this further and figured that the ClientConn is in fact virtual and can point to non-existing endpoint. This would certainly make sense to create a client early on and reuse (e.g. endpoint does not need to be up and running at the time of client generation), and the doc here provides the exact details around it. – Ryota Oct 16 '19 at 23:51