Inter-Service Communication with gRPC- Chapter 1

To begin with, let’s start with the meaning of gRPC. gRPC is RPC(Remote Procedure Calls) framework developed by Google. The naming of gRPC is dynamic one just as android versions(Google loves it). Below is a list of already-used definitions (that should not be repeated in the future), and the corresponding version numbers that used them:

• 1.0 ‘g’ stands for ‘gRPC’
• 1.1 ‘g’ stands for ‘good’
• 1.2 ‘g’ stands for ‘green’
• 1.3 ‘g’ stands for ‘gentle’
• 1.4 ‘g’ stands for ‘gregarious’
• 1.6 ‘g’ stands for ‘garcia’
• 1.7 ‘g’ stands for ‘gambit’

In gRPC a client application can directly call methods on a server application on a different machine as if it was a local object, making it easier for you to create distributed applications and services.In gRPC we define a service and specify the methods that can be called remotely.The server implements this interface and runs a gRPC server to handle gRPC client calls.On the client side, the client has a stub that provides the same methods as the server.

gRPC supports many languages like Go, Python, Java, C++,Ruby etc.

gRPC uses Protocol Buffers which is again a brand new term. Protocol Buffers is a way to define the structure of data that you want to serialize. To be more understandable its just like json or xml.Once we define the structure of data in a file with .proto extension, we use protoc compiler to generate data access classes in your preferred language(s) from your proto definition.To read more about the Protocol Buffers, follow this link. Protocol Buffers.

Here is an example of .proto file, how to compile it into a Go code and sample gRPC client and server code.

sample.proto

service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
  // Sends another greeting
  rpc SayHelloAgain (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

Compilation.

protoc -I <directory_name>/ directory_name/sample.proto --go_out=plugins=grpc:sample

Go Client

r, err = c.SayHelloAgain(context.Background(), &pb.HelloRequest{Name: name})
if err != nil {
        log.Fatalf("could not greet: %v", err)
}
log.Printf("Greeting: %s", r.Message)

Go Server

func (s *server) SayHelloAgain(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
        return &pb.HelloReply{Message: "Hello again " + in.Name}, nil
}

One question that immediately clicked in my head after reading about gRPC and am sure will click anyone’s mind is how is it different from REST. Afterall its based on RPC which is just a communication protocol then why not REST?Here is the comparison between the two on following parameters.

Speed

gRPC is faster than REST. gRPC uses HTTP2 by default and in addition, it uses Google’s protocol buffers (you don’t have to) for encoding, the information comes on and off the wire much faster than JSON. Latency is an important factor in several companies. JSON encoding is an actually a noticeable portion of the latency when profiling. For distributed and data heavy application architecture, gRPC actually makes a noticeable difference.

Robustness

gRPC defines relationship between client and server and enforces strict rules of communication between them. In REST calls, the request and response are totally de-coupled: you can send anything you like and hopefully the other end understands what to do with it. We need to update both the server and the client(in case of gRPC) to keep things working when you make changes.It prevents mistakes specially in microservice architecture.For a typical microservice based platform, gRPC marks its importance.

Additional Advantages

1. gRPC supports useful additions like standard error responses and meta data.For eg. if “Client Application cancelled the request” then code “Cancelled” will be generated at both Client and Server Side.Or if “Method not found at server” then “UNIMPLEMENTED” will be generated at Server Side.For more status codes follow this link StatusCodes.
2. It keeps communication pipe open between phone app and backend service and hence very useful for creating low latency mobile applications.
3. Because requests can be tracked using the same context through multiple services, it’s possible to cancel requests on different systems or trace them to see what is causing delays.
4. gRPC is much more efficient if you re-use connections, so if you know you’re going to use the same connection again, keep it open.

Downsides of gRPC

Currently, the browser support for gRPC is not good. Hence, whenever any request is created by some client browser, we can’t trust gRPC there. That’s why ,currently, its best suited for inter micro service communication. In the future versions of gRPC, this issue will be resolved.

Conclusion

gRPC will be making a big name in coming future and specially for organisations adopting microservice architecture.

We will be covering difference between REST server and gRPC server, connect and teardown in HTTP1.1 REST services and its comparison with channel creation and few other things in coming chapters.