gRPC Sample in C++ and Python

i resorted to using boost::asio (which is on its way into c++17 , by the way) to ease on the details in the c++ server. but even boost::asio won't do everything for you; for example, actually putting serialized protobufs on the wire requires additional mechanisms like length-prefixing and a special enumeration value in every message to select the request type ("message polymorphism"). it's a lot of custom coding for a problem that was solved long ago.

the reality is that i was hand-rolling a simple rpc implementation. now, in 2016, it's no longer necessary as google has recently open-sourced grpc , the yang to the protocol buffers yin. grpc expands the protobuf specification to define rpc services and then auto-generates server and client code from them, taking care of the whole networking layer. all you have remaining is to implement your custom application logic. grpc is very new (still in beta, and only released last year), but it's a rewrite of the google-internal stubby system which has been used for at least a decade for the same purpose. google appears to be committed to maintaining grpc in the long haul since it uses it as the api for some of its cloud offerings.

the code for the new sample is available in full here . here is the message/service definition:

syntax = "proto3";

package stringdb;

service stringdb {
 // get the value stored on the server for a given key
 rpc getvalue (getvaluerequest) returns (getvaluereply) {}

 // set the server's value for a given key
 rpc setvalue (setvaluerequest) returns (setvaluereply) {}

 // count the size of the server's value for a given key
 rpc countvalue (countvaluerequest) returns (countvaluereply) {}
}

message getvaluerequest {
 string key = 1;
}

message getvaluereply {
 // empty string returned when key not found on the server.
 string value = 1;
}

message setvaluerequest {
 string key = 1;
 string value = 2;
}

message setvaluereply {
 // returns the value.
 string value = 1;
}

message countvaluerequest {
 string key = 1;
}

message countvaluereply {
 // returns the size of the value, in bytes. if key isn't found on the server,
 // returns -1.
 int64 count = 1;
}

it's longer than before because now it also specifies the service, which is an rpc contract that the server and the client implement. we get a lot of buck from grpc for this simple definition, because now the networking server logic is rolled into ~10 lines of c++ code. the vast majority of the code is spent implementing the server-side rpc methods. here's an example:

grpc::status getvalue(grpc::servercontext* context,
 const stringdb::getvaluerequest* request,
 stringdb::getvaluereply* reply) override {
 // get data from request; do work; populate reply; return a status.
 return grpc::status::ok;
}

on the python side, all the client has to do is:

channel = implementations.insecure_channel('localhost', port)
stub = stringdb_pb2.beta_create_stringdb_stub(channel)

...

# invoke methods on the stub...

request = stringdb_pb2.countvaluerequest(key=key)
response = stub.countvalue(request, timeout_seconds)
return response.count

it's quite incredible how much code grpc saves you from writing... just compare to the previous sample!

but, that's not all. what i have here is a very simplistic service. grpc gives us many advanced features out of the box that would take serious time investment to implement:

• http/2 support out of the box (reduced latency over traditional http servers)
• multi-language support for the network layers, not only data (de)serialization. want to write your server in go and client in objective-c? no problem
• performance through thread pools and other server implementation variations
• authentication with ssl/tls or oauth
• blocking and non-blocking servers and clients
• streaming
• flow-control
• cancelation and timeouts on rpc calls

installing grpc on an ubuntu box was pretty simple. i just went through the instructions in their install.md file to build and install it from source. the python plugin and related code can be installed with pip (be sure to use a virtualenv). one small wrinkle i ran into is that you also have to "make install" the protobuf library (pulled in as a git submodule by the grpc checkout process). even though grpc's makefile compiles it, it doesn't install it.

link to the code .