gRPC: The Good, The Bad, The Ugly

gRPC (Google's Remote Procedure Call) is an open source remote procedure call system initially developed at Google in 2015 as the next generation of the RPC infrastructure Stubby.

It is thought to be based on their internal RPC Systems used for products such as Google Cloud Platform, AdSense and some parts of YouTube. Other Tech Companies such as Netflix, Cisco, Medium and Uber also use this in some of their services.

The Good

Has great cross-language support

The contracts - (made in .proto files) can be generated into objects/functions/classes of any supported language - which include (but not limited to): C#, C++, Dart, Go, Java, Kotlin, Node, Objective-C, PHP, Python, Ruby.

Forces looser coupling between microservices

gRPC framework pushes well-defined messages, versioning and contracted endpoints. The framework runs over the newer HTTP/2 protocol and exchanges data in a binary format. Under the hood, a number of other differences are present that make gRPC worth a closer look.

Allows for Type-Safe APIs

Unlike JSON (for REST APIs), we can specify field types and add validations for the same in the .proto definition file. This means that both sides are aware of the structure and types that it expects to receive from the server.

The Bad

Lack of developer tooling

Many tools we use today are designed for HTTP/1, moving to HTTP/2 and Protobuffers requires a whole new set of Dev Tools. Some tools are starting to emerge, most of which have not gained any popularity yet. This can make the Developer have a worse time when trying to debug/test gRPC Endpoints.

Limited insight into common practices

There are very limited stories around what has been working, as well as what workarounds are required, and how to support gRPC in production. Hopefully this will get better, but currently common practices and anti-patterns haven't been set out by Google.

Not an option for edge caching

This is a deal-breaker for some. While HTTP supports intermediaries for edge caching, gRPC calls use the POST method, which isn't the best. gRPC responses cannot be cached through intermediaries (RPC Contracts) as is the case with REST-based APIs that use the GET verb for resource representation requests.

The Ugly

No Code-First Approaches (Yet)

The only annoyance (that I personally have) about the way you develop APIs with gRPC, is that you are always having to repeat any new fields (that you want retrievable from the Client) within the Entity itself and the Protobuf definitions itself. For example, if I wanted a new name attribute in this class:

public class SomeEntity {

    /* .....Previous Fields here..... */

    private String newField;

}

I'd then have to reflect this change in my corresponding .proto file, which can be a pain, especially if the type wanted isn't available in the proto3 syntax (which is a rare case - but possible)

message SomeEntity {
    # Previous Fields here
    string newField = 4;
}