Should you choose gRPC over REST when designing your APIs?

This article was available first on TechBullion - read it here.

If you head up a development team, then choosing which architectural style to use is a critical decision to make when building up an IT infrastructure. APIs remain an important part of this decision making process; they are mediators through which information is sourced and transferred. If you want to interact with another computer or software system to retrieve information or perform a function, an API helps you communicate with that system so it can understand and fulfil the request.

REST: the gold standard for web APIs

For years, REST (Representational State Transfer) has been the gold standard for building web APIs, and is a set of principles that dictate how a web service should behave and interact with clients. With them, developers can quickly set up a web server that can then share information with every web browser that connects to it. REST is simple and easy to use, requiring less coding than its counterparts. This simplicity and scalability means it can accommodate large volumes of request, and so it is often deployed horizontally across applications in order to reduce network traffic and improve performance. REST APIs are also frequently used in other places such as mobile applications and microservices. 

This simplicity does come at a cost though; although REST is a well-defined architectural style, there are no standardised rules for its implementation. This can lead to inconsistency and unpredictability in how different APIs are designed and implemented. REST also communicates via HTTP request-response cycles, which are not designed for real-time interactions and can carry significant overhead costs due to the large amounts of data that need to be transferred. 

gRPC has entered the chat

Developed by Google and released to the public in 2015, gRPC is an open-source remote procedure call (RPC) framework that enables clients and servers to communicate with each other transparently and efficiently. While REST is more akin to sending a letter and then getting a response with a letter, the flow of gRPC is more like having a phone conversation; the exchange of information is both continuous and instantaneous. With gRPC, one program can send a message to another program, and they can have a back-and-forth conversation, called a “stream,” without having to wait for each message to be sent and received separately.

Alongside this more natural way of communicating, the gRPC API is designed for high-performance applications and can handle a large number of requests efficiently, working with multiple programming languages, making it easy to build polyglot applications. 

It also has the benefit of time; gRPC API supports modern features like HTTP/2, Protocol Buffers, and service discovery, which can help build more robust applications.

gRPC is a powerful and efficient framework but, like REST, it does have some limitations that should be considered when choosing it as a solution. Its complexity means it can be challenging for some developers to learn and implement, and it may not be compatible with existing APIs or libraries due to its reliance on the newer HTTP/2 protocol. Finally, while gRPC provides built-in support for features like authentication and load balancing, it may require additional configuration and setup to be fully functional in complex environments.

What to choose: REST or gRPC?

It comes as no surprise that this decision will be based on the needs of what it is you are building, and what you are building it with. REST may look outdated when compared to gRPC, but it does have the benefit of being simple to understand, and more universally compatible with existing infrastructure. To that end, if you are looking to deploy something quickly into an existing (non-gRPC) environment, then REST provides the ideal “out of the box” solution. However, given the additional efficiency offered by gRPC, this may be the more sensible solution if you are looking to build robust future-proof applications. 

This article was available first on TechBullion - read it here.