Last week I published a short comparison between different (web) programming languages that could be used for developing microservices. As our team experimented with the Go language we stumbled across the gRPC. Before we dig into gRPC lets get one thing out of the way. When I talk about REST, I basically mean serving JSON over HTTP1.1 based on endpoints that relate to specific HTTP verbs (i.e. GET/PUT/POST etc).
In some sense you could argue that gRPC is a step back from REST. RPC is older than REST. In fact REST can be described as a successor to gRPC is however a very modern take on fast communication between to machines.
One of the problems of a RESTful API is the fact that it is relatively slow with a significant overhead. gRPC tackles this by using more efficiënt protobufs for communication as opposed to JSON. The drawback is that the protobuf messages are not in a human readable format and have to be defined beforehand. In my personal opinion these two facts are a huge drawback compared to the flexibility of REST, which will have it’s toll on the development process. Finally gRPC is not as widely supported as REST api’s are, in order to use it with PHP you have to install an additional plugin.
Does that mean that gRPC is entirely useless. Not at all. Let’s list a few of the advantages over REST:
- It supports (bidirectional) streaming as well as the traditional request model.
- It defaults over HTTP/2 , and is therefore faster.
- gRPC is automatically encrypted.
- It features strong typing.
- It supports a range of authentication methods.
- It is significantly faster because the amount of data that is send is smaller.
The main takeaway from this short analysis is that there are certain use cases in which it can be advantageous to make use of gRPC. If you need high performance internal communication between your microservices it might be worth your while. However because it’s complexity I do not it will take some time before it is a reasonable replacement to offer your end-users. For now it could also be offered as a quick alternative alongside REST to be prepared for the eventual transition to HTTP/2.