Choosing gRPC
Here at Namely, we are developing new microservices to build a better HRIS platform. Like any distributed architecture, we need a way for each microservice to communicate with the others in a fast and efficient manner. There are many solutions for this problem. For Arnoldb, we decided we wanted to use an RPC protocol. We needed something that would provide interoperabilility between different software languages. While we wanted it to be fast, we also didn’t want to roll out our own TCP protocol. In addition, we wanted to use Protocol Buffers. After much research, we came upon gRPC. Here, we’ll discuss what we learned and why gRPC is awesome.
What is RPC?
Remote Procedure Call (RPC) is a technique in computer science for calling a function in a different address space (usually on a separate computer across the network). It allows a developer to write code that will work whether desired subroutine is local or on a remote machine. Essentially, it allows us to use a microservice in a way that feels like it were a part of a monolith system.
Protocol Buffers and gRPC
In a previous post, we touched on how awesome Protobuf is. With gRPC, Google has released the next iteration of Protobuf with Proto3. Proto3 brings many upgrades and fixes. First, it simplifies the language a little by removing field presence. In Proto2, you could specify whether a field was optional or required which made the compiler implementation in languages like Go or Objective-C more complicated. In Proto3, all fields are optional. Another major feature is the addition of the Map Type. The map type works just like a dictionary or associative map in any other language. When used with an RPC library such as gRPC, you can even define your RPC service and all the calls in the protobuf source file.
Set on gRPC
For Arnoldb, we are using Google’s Go. The language has tons of built-in functionality: right-out-of-the-box, it supports RPC. However, the implementation of RPC uses a Go-specific encoding known as GOB, which doesn’t play well with other languages. The microservices we are building at Namely are meant to be language agnostic. Since Namely uses Ruby, at the very least, our microservice has to communicate between Go and Ruby.
While Searching for an alternative RPC solution, we came across gRPC. It’s an open source framework for RPC by Google. According to the company:
“gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. It enables client and server applications to communicate transparently, and makes it easier to build connected systems.”
gRPC uses HTTP/2 and Google’s own Protobuf to provide a scalable and low latency communication. With gRPC comes a new version of Protobuf (proto3) for high performance binary serialization which includes new features and is easier to use than its predecessors. It’s also built on top of the new HTTP/2 protocol which offers many advantages over its predecessor, HTTP/1.1, including header compression, and multiplexing many requests over a single TCP connection. In addition, gRPC supports a wide array of libraries, including Ruby, Java, C/C++, Go, and more.
