Saran

I am an Android developer with passion for builing slick animations and user interfaces.

4 minute read

Gone are the days when we used to use SOAP for exchanging data between mobile and server. REST has become the default for transferring data between the client and the server. However, there is a new kid in the block which is getting popular: gRPC or Google Remote Procedural Call. Here procedure means a function ie: Google Remote Function Call. So like functions we define, it takes some input parameters and does some processing on it and then returns a response. gRPC is nothing novel, but pretty basic. We create a contract of what will be sent from one end and received on the other end using a .proto file. Then we send the actual message as bytes based on the defined contract.

Example helloworld.proto

syntax = "proto3";

option java_package = "io.grpc.examples.helloworld";

package helloworld;

// 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;
 int32 message_length = 2;
}

Here we are defining 1 API call named SayHello. We need to provide the HelloRequest as input to this API and HelloReply is what is returned from the API.

HelloRequest has a name field in it of type String.

HelloReply has a message field in it of type String, and also message_length of type int.

Additionally, we would also use a protobuf plugin to generate the Models for the Request and Responses and Stubs for the RPC call, in different languages like Java, Python, Go, C++ or Objective C. Now when the server implements the SayHello rpc, and a client makes a call to this rpc with the HelloRequest using the stub generated by the protobuff plugin, the server will return a HelloReply response.

The generated code can be quite a lot for mobile clients, thus the Protbuff plugin 2 options: Regular and Protobuf-lite. Regular is meant to be used by servers where it’s ok to generate a little extra code without much cost. On mobile, generating a lot of code will quickly add up, since Classloader will have to load all this extra class. Also, it will increase the App download size significantly. Thus on mobile, it’s recommended to use protobuf-lite version, which generates relatively lesser code.

Pros of using gRPC for mobile apps

  • Reduced network bandwidth when compared to REST is significantly lesser because when using data types like JSON, there is no pre-defined contract between Server and Client. This means, the messages transmitted need to include a key, which says what data we are passing and the actual data. EG name: “Saran”. Here name is the key and “Saran” is the value. Whereas the client only needs the value “Saran”. Which causes increased response size. While in gRPC, since the contract is formally defined as a protobuf file, only the actual value needs to be transmitted.
  • Clearly defined contracts, which means communication between the Backend team and Client team is efficient, and there is no scope for miscommunication. Whereas, in REST this contract is not formally defined, which means the client and server can have different understandings of them.
  • Support for unidirectional and multi-directional streaming. Which is often required when we have to upload files or continuously stream data like stock prices from the server.

Cons of using grpc for mobile

  • Increased App size in the long run. This is because even if use protobuf-lite it still generates a lot of code, whereas libraries like Retrofit in combination with gSON or Moshi make things a lot more efficient when using REST.
  • Lack of resources and tooling support. When compared to REST which has gotten mature over time, especially on the client side there is an ample amount of resources and tooling which makes debugging or solving a complex challenge easier. However, since gRPC is new there are fewer resources and tools. Also, since gRPC is protobuf based all the tools need the .proto file to understand the request and response which only adds complexity to the tooling support.
  • Rigid: Because gRPC is protbuf-based, the contracts are very strict and it’s not easy to make new changes. To change, we have to update the proto file, generate both client and server codes from the proto file and then implement them. This is time-consuming.

Conclusion

Yes, gRPC is great for mobile apps especially due to the reduced transmission size of data. Reduced data to be transmitted means, faster transfer even when on slow internet. However, we still need better tooling support for gRPC because without them debugging becomes very difficult. Whereas tools like Stetho by Facebook makes debugging network calls as easy as a breeze.

You May Also Enjoy