gRPC is essentially a modern remote procedure call technology that supports multiple programming languages. The focus of this analysis is to show how the use gRPC would compare to the typical REST API approach for applications and illustrate the key differences between the approaches. The diagram below shows how gRPC is used to integrate clients and servers using multiple programming languages.
Static Typing of Interfaces
gRPC supports strong typed interfaces. This is a major departure from REST APIs, as REST does not provide typing for interfaces. Strong typed interfaces have significant benefits. In multi-team, multi-component systems, strong typing prevents a host of coding errors and communications issues. This benefit is typical of other approaches that use strong typing, such as COM, CORBA and SOAP. The down-side to this approach is that this requires heavier-weight tooling compared to REST. Whereas REST APIs can be called directly from a web browser, gRPC requires modules to be included in all client and server components. This imposes requirements on clients and servers, because they must leverage the gRPC toolkit.
Performance and Efficiency
gRPC uses Protobuffer to implement binary serialization of messages, which is much more efficient than text-based XML and JSON used with REST services. gRPC also uses the HTTP 2.0 protocol, which is multiplexed, supports header compression and is more efficient than the HTTP 1.1 protocol used by most REST libraries. This is particularly useful when dealing with slow connections between clients and servers. As a result of the use of the HTTP 2.0 protocol, gRPC is typically faster than REST, especially when using REST over HTTP 1.1.
Both gRPC and REST have polyglot programming language support. This is particularly useful for interfacing with legacy programming languages like C++ and in heterogenous, cross-organization environments where multiple development languages are used. This allows the best programming language for each component to be used, as both technologies support C++, Java, Node.js, Go and many other languages.
In addition to synchronous request-response processing, gRPC also supports flexible request-response streaming. This allows for streaming of requests, responses or requests and responses. While REST can support asynchronous communications, this is typically only used for communications between backend components as this is not supported over HTTP 1.1 because it requires additional components to support asynchronous messaging.
Nearly Serverless Implementation
gRPC is a nearly serverless approach. It doesn’t require infrastructure components such as Java containers and application servers like JBoss and Tomcat, Scala infrastructure like Spray and DSL, or any other server-side components typically associated with C++ or SOAP based approaches. The gRPC server libraries support most languages but do not lock you in to a specific “serverless backend” service provider. REST, on the other hand, requires server-side infrastructure.
Web GUI Integration
Web GUI integration using gRPC can be a challenge for web-based interfaces. Unlike REST APIs, gRPC implementations cannot be called directly from a web browser. Front-end integration for web UIs requires additional work. This typically requires a backend that exposes a REST API for front-end components while orchestrating among the multiple back-end micro-services or using a proxy server to proxy the HTTP 2.0 calls to HTTP 1.1. This is obviously not required for REST APIs and services.
The development process using gRPC is a bit more complex than for REST applications. Defining REST services is a well-understood process and the best practices are generally well-known. In contract, gRPC best-practices are not as well known in the application development community. As a result, the development process tends to be slower. Additional time is typically required to build tooling and for testing services. Many configuration options are not well documented and require a review of the source code to decipher. Development teams also tend to run into issues with how Protobuffer handles default values compared to how those values are handled in your development language of choice. Testing tools are relatively limited as well, compared to tools for testing REST services.
Load balancing is also a challenge for gRPC’s services. gRPC uses the HTTP 2.0 protocol, which achieves lower latency in part by leveraging a single long-lived TCP connection to multiplex request and responses across it. This causes a problem for layer 4 (L4) load balancers as they operate at too low a level to be able to make routing decisions based on the type of traffic received. A L4 load balancer attempting to load balance HTTP/2 traffic will open a single TCP connection and route all successive traffic to that same long-lived connection, which effectively cancels out the load balancing. A Layer 7 load balancer is required to support gRPC services. REST does not have this issue, as it is based on HTTP 1.1.
gRPC is not as mature as REST, but that is to be expected. Additional tools to support load balancing, simplify clustering and failover, and streamline the testing and debugging process are starting to appear for gRPC. These tools are not as mature as REST tooling.
gRPC is an open source technology created by Google. Building on top of this platform essentially locks you in to this approach, as applications built on this technology cannot easily be migrated to another technology stack. While REST has similar drawbacks, there are many libraries and toolkits that support REST services, and it is relatively easy to migrate from one toolkit to another.
There many scenarios where gRPC would be advantageous over traditional REST services. However, the choice to use gRPC or REST should be based on the specific use cases and requirements for a given application.