Grpc makes api update easier

I'm working on an API update today, I will need to add more fields in both the request parameter and api response. thanks to GRPC's elegant design , I could update the API fields and apply to production without worrying about any backward compatibility.

GRPC's message is based on protocol-buffers, a language-neutral, platform-neutral, extensible mechanism for serializing structured data. all the GRPC APIs are designed in protocol-buffers, a hello world type of grpc api definition could be found in one of my project grpc-mate's protobuffer package helloworld.proto

syntax = "proto3";
option java_package = "io.datanerd.generated.helloworld";
option java_multiple_files = true;

// The greeting service definition.
service Greeter {
    // Sends a greeting
    rpc SayHello (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;
}

the request and response are just one protobuf message. with this design, I could add more fields in the request and response, but the API still remains the same. for example, I want to add a new field in HelloReply to indicate response date, I could do the following

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

the GRPC client and the server normally does not deploy together, we could update server first to include today field, when client have not update the protobuf file, even server response HelloReply contains today field, due to client has not updated, it still work, but just ignroe today field in the HelloReply message. this feature is super useful for the application which is already in prodcution mode, we could update server first anad the server clould support client call no mater it update the protobuf or not. there are some other benefits we could get from GRPC, I will discuss them in other articles