GRPC Connection Management in Golang

Question

I am relatively new to GRPC and want to be sure that I am doing connection management correctly with golang. I don't want to have to create a new connection for every call but I also don't want to create bottlenecks as I scale.

What I did was to create a single connection in the init function:

var userConn *grpc.ClientConn
var userServiceName string

func init() {
    userServiceName := os.Getenv("USER_SERVICE_URL")
    if userServiceName == "" {
        userServiceName = "localhost"
    }
    logging.LogDebug("userClient:  Connecting to: "+userServiceName, "")
    tempConn, err := grpc.Dial(userServiceName, grpc.WithInsecure())
    if err != nil {
        logging.LogEmergency("account_user_client.Init()  Could not get the connection.  "+err.Error(), "")
        return
    }
    userConn = tempConn
}

And then for each function I will use that connection to create a Client:

c := user.NewUserClient(userConn)
// Contact the server and print out its response.
ctx, cancel := context.WithTimeout(context.Background(), time.Second)
defer cancel()
r, err := c.GetUserFromTokenID(ctx, &user.GetUserFromTokenRequest{TransactionID: transactionID, OathToken: *oathToken})
//Handle Error and Response

is this an acceptable way to handle grpc connections? Any recommendations on better ways?

Thank you very much.

Answer 1

Yes, it's fine to have single GRPC client connection per service. Moreover, I don't see any other options here. GRPC does all the heavy lifting under the hood: for example, you don't need to write your own client connection pool (as you would do for a typical RDBMS), because it won't provide better results than a single GRPC connection.

However I would suggest you to avoid using global variables and init functions, especially for networking setup. Also you don't need to create GRPC client (c := user.NewUserClient(userConn)) every time you post a request to the GRPC service: this is just an extra work for garbage collector, you can create the only instance of client at the time of application startup.

Update

Assuming that you're writing server application (because it can be seen from the method you call on the remote GRPC service), you can simply define a type that will contain all the objects that have the same lifetime as the whole application itself. According to the tradition, these types are usually called "server context", though it's a little bit confusing because Go has very important concept of context in its standard library.

   // this type contains state of the server
   type serverContext struct {
       // client to GRPC service
       userClient user.UserClient

       // default timeout
       timeout time.Duration

       // some other useful objects, like config 
       // or logger (to replace global logging)
       // (...)       
   }

   // constructor for server context
   func newServerContext(endpoint string) (*serverContext, error) {
       userConn, err := grpc.Dial(endpoint, grpc.WithInsecure())
       if err != nil {
           return nil, err
       }
       ctx := &serverContext{
          userClient: user.NewUserClient(userConn),
          timeout: time.Second,
       }
       return ctx, nil
   }

   type server struct {
       context *serverContext
   }

   func (s *server) Handler(ctx context.Context, request *Request) (*Response, error) {
       clientCtx, cancel := context.WithTimeout(ctx, time.Second)
       defer cancel()
       response, err := c.GetUserFromTokenID(
          clientCtx, 
          &user.GetUserFromTokenRequest{
              TransactionID: transactionID,
              OathToken: *oathToken,
          },
       )
       if err != nil {
            return nil, err
       }
       // ...
   }

   func main() {
       serverCtx, err := newServerContext(os.Getenv("USER_SERVICE_URL"))
       if err != nil {
          log.Fatal(err)
       }
       s := &server{serverCtx}

       // listen and serve etc...
   }

Details may change depending on what you're actually working on, but I just wanted to show that it's much more better to encapsulate state of your application in an instance of distinct type instead of infecting global namespace.

Answer 2

A few things make this implementation work.

1. gRPC channel (i.e, c from c := user.NewUserClient(userConn)) is backed by a http/2 connection. It will automatically reconnect or retry connection when the connection is closed or dead.

2. http/2 supports messages to be sent concurrently within a single connection. Considering this scenario, service Order makes one product stock get, product stock update and product coupon change to service Product at a time. The three grpc requests can reuse the single http/2 connection, and grpc will process the data exchange concurrently. So it's okay to just use one connection, instead of creating three connections (like http/1) to achieve this.

3. To avoid premature optimization, one connection should be okay to start for a service. In case pool performance in future, consider creating one separate tcp connection (then separate http/2 connection) for hot spot grpc requests.

It might be good to keep connection alive, in case some proxy might kill the idle connection. See more explanation at https://github.com/grpc/grpc-go/blob/master/Documentation/keepalive.md, and example code at https://github.com/grpc/grpc-go/tree/master/examples/features/keepalive.

For gRPC vs http/2 connection, check https://grpc.io/blog/grpc-on-http2/#a-robust-high-performance-protocol and https://www.cncf.io/blog/2018/07/03/http-2-smarter-at-scale/.