by Jeremy H • September 4, 2020
REST dominates the modern API landscape, especially when it comes to web applications and microservices-based infrastructures. However, REST isn’t the only API architecture available, and for a certain set of use-cases, the gRPC model has begun to play a small but crucial role.
Whether you’re trying to figure out what “gRPC” means — or you’re considering gRPC as an alternative to REST APIs for your next development project — this guide will help you understand what gRPC is, why people use it, and how a gRCP API compares to a RESTful API.
We’re going to cover a lot of ground so feel free to use the following links to navigate:
Sign up for our free 14 day hosted trial to learn how.
To understand REST and gRPC, we need to start with APIs (application programming interfaces). APIs provide rules and definitions that allow applications to communicate and interact with each other. An API defines the types of calls and requests that one application can make to another, how to make those requests, the data formats to be used, and the conventions that clients must follow.
APIs also support the “pluggability” of applications that form a larger system because they allow two applications – even if they were written in different programming languages and running on different platforms – to communicate and interact with each other.
REST APIs and gRPC APIs refer to different architectural styles for building APIs. Here’s a brief definition of both:
Here’s a simple matrix that compares the basics of REST APIs and gRPC:
One of the best ways to understand the topic of APIs is to view APIs in the context of modern, microservices-based application development. Not only do APIs make microservices-based applications possible, but it’s in the context of microservices-based applications that gRPC APIs can — in some cases — serve as an alternative to REST APIs.
Microservices-based applications overcome the biggest limitations of traditional, monolithic applications. A monolithic application contains the programming for all of its services and features within a single, indivisible code-base that manages all of the services and features of the application.
The problem is that — as developers bolt new services and features on top of the existing framework — it becomes increasingly difficult to modify, upgrade, and scale the application. Changing one part of the app can negatively impact other areas. After scaling, updating, and changing a monolith multiple times, the codebase eventually becomes so interdependent and difficult to understand that it’s necessary to redesign the entire system from scratch.
A microservices-based application architecture resolves this problem. This architectural style involves breaking a monolith into its component services and running each component as an autonomous application (called a microservice). These individual microservices then use APIs to interact and interact with each other. Together, this API-connected group of microservices forms the larger application architecture.
Because of the way APIs allow autonomously-running microservices — even those coded in different languages and running on different platforms — to connect with each other, APIs allow you to achieve a pluggable, component-based system. Upgrading individual microservices is dramatically faster and easier because the changes you make to an autonomously-running service have less impact on the entire system. Scaling is easier and more efficient because resources can be diverted to the microservices that need it based on usage demands. Moreover, if one microservice fails or slows down, it’s less likely to bring down the entire infrastructure. All of this translates into more efficient, resilient, scalable, and flexible systems — and APIs are what make it all possible.
The most widely-used architectural style for APIs is the REST API. However, there are also RPC APIs and gRPC APIs. In the next sections, we’ll look at how these APIs compare to each other.
REST (Representational State Transfer) describes a client-server organization in which back-end data is made available to clients through the JSON or XML messaging format. According to Roy Fielding, an API qualifies as “RESTful” when it meets the following constraints:
Finally, the REST API architecture generally relies on HTTP protocol, and REST APIs are the most common format for building web applications and connecting microservices. When a REST API is made publicly available as a web service, each component (or service) provided by the web service is presented to clients as a resource. Clients can access these resources via a common interface that accepts different HTTP commands like GET, POST, DELETE, and PUT.
As a predecessor of REST, RPC (Remote Procedure Call) is a software architecture dating back to the 1970s. RPC allows you to invoke a function on a remote server in a particular format and receive a response in the same format. It doesn’t matter what format the server executing the request uses, and it doesn’t matter if it’s a local server or a remote server. RPC allows you to invoke a function on the server and receive the result in the same format.
The basic concept of an RPC API is similar to that of a REST API. The RPC API defines the rules of interaction and what methods a client can use to interact with it. Clients submit calls that use “arguments” to invoke these methods. However, with an RPC API, the method is found in the URL. The arguments that invoke the methods are found in the query string. To illustrate this, here’s how an RPC API request compares to a REST API request:
As a variant of the RPC architecture, gRPC was created by Google to speed up data transmission between microservices and other systems that need to interact with each other. Compared to REST APIs, gRPC APIs are unique in the following ways:
Let’s take a closer look at each of these differences between REST and gRPC APIs.
Both REST APIs and RPC APIs send and receive messages using the JSON or XML messaging formats. They can use other formats too, but JSON and XML are the most common. Of these, JSON has become the most popular format because it is flexible, efficient, platform neutral, and language agnostic. It’s also text-based and human-readable, which makes it easy for human operators to work with. The problem is that for certain use-cases, JSON isn’t fast enough or light-weight enough when transmitting data between systems.
In contrast to REST and RPC, gRPC overcomes issues related to speed and weight — and offers greater efficiency when transmitting messages — by using the Protobuf (protocol buffers) messaging format. Here are a few details about Protobuf:
Another way that gRPC boosts efficiency is through its use of the HTTP 2 protocol.
REST APIs are usually built on HTTP 1.1, which uses a request-response model of communication. This means that when a microservice receives multiple requests from more than one client, it has to serve them one at a time, which slows the entire system. REST APIs can also use HTTP 2, they are still limited to the request-response model and don’t take advantage of HTTP 2 support for bidirectional, streaming communication.
In contrast, gRPC uses HTTP 2 and it takes advantage of HTTP 2 support for both client-response communication and bidirectional communication. As such, gRPC can manage “Unary” interactions that are similar to HTTP 1.1 (where the client sends one request and the server sends one response). At the same time, clients can also open long-lived connections where each RPC call opens a new HTTP 2 stream — also known as bidirectional, “multiplexing,” or streaming communication.
In HTTP 2, when a microservice receives multiple requests from more than one client, it achieves multiplexing by serving many requests and responses simultaneously. In this respect, gRPC APIs depart from the limitations of REST APIs in their capacity to stream information constantly.
There are three types of streaming that gRPC makes available:
Code generation features are native to gRPC via its in-built protoc compiler. With REST APIs, it’s necessary to use a third-party tool such as Swagger to auto-generate the code for API calls in various languages.
The protoc compiler that comes with gRPC is compatible with a wide range of programming languages. This makes gRPC excellent for polyglot environments — where you are connecting a lot of different microservices that are coded in different languages and running on different platforms.
In contrast, REST API does not offer native code generation features. You have to use a third-party tool like Swagger to generate code for API calls in different languages. This isn’t an inconvenience, but it’s worth noting that gRPC doesn’t depend on any external tools for code generation.
According to widely-cited tests published by Ruwan Fernando, gRPC API connections are considerably faster than REST API connections. In fact, he reported that they are 7 to 10 times faster:
“gRPC is roughly 7 times faster than REST when receiving data & roughly 10 times faster than REST when sending data for this specific payload. This is mainly due to the tight packing of the Protocol Buffers and the use of HTTP/2 by gRPC.”
Despite the benefits in message transmission speed, gRPC API implementation is a great deal slower than REST API implementation. According to Ruan Fernando, it takes approximately 45 minutes to implement a simple gRPC Service. It only takes about 10 minutes to implement a Web or REST API.
Fernando reports that the additional implementation time reflects the lack of in-built support for gRPC in third-party tools. This is primarily because gRPC is not yet widely adopted, especially compared to the ubiquity of REST APIs. Here’s what Fernando says about gRPC implementation time:
“I had to spend roughly 45 mins implementing this simple gRPC Service, where I only spent around 10 mins building the WebAPI. This is mainly due to REST becoming mainstream a long time back, and most major frameworks (i.e. ASP.NET Core MVC) having built-in support to quickly spin up such services (through convention & patterns).”
Let’s compare when you should consider using REST APIs vs. gRPC APIs:
REST APIs are the most widely-used and popular APIs for connecting microservices-based infrastructures. Whether you are building an internal system or an open system that exposes its resources to the rest of the world, REST APIs are likely to remain the de facto choice for app integration for a very long time. Also, REST APIs are ideal when a system needs high-speed iteration and standardization of HTTP protocol.
With its universal support from third-party tools, REST APIs should be your first consideration for app integrations, microservices integrations, and web services development.
As for gRPC, most third-party tools continue to lack in-built features for gRPC compatibility. As such, gRPC is mostly relegated to building internal systems, i.e., infrastructures that are closed to external users. With that caveat in mind, gRPC APIs could be useful for the following circumstances:
Due to the various advantages of gRPC APIs that we have covered so far, some developers see gRPC as the “future.” However, these developers could be getting ahead of themselves. gRPC is not yet widely adopted, and it remains to be seen whether its benefits will spur greater adoption in the future.
In comparison, REST is supported universally and virtually every microservices-based infrastructure depends entirely on REST APIs as the glue that holds them together. Unless your use-case demands gRPC implementation, taking the risk to adopt gRPC at this nascent stage (before widespread adoption) is neither practical nor necessary.
REST APIs development is a vital part of developing a modern, microservices-based application architecture. However, coding a simple REST API can take weeks when you do it by hand — which represents significant labor costs and delays for your project.
This is where the DreamFactory iPaaS and API gateway can help. One of the most useful features of the DreamFactory platform is its capacity to automatically generate REST APIs. With DreamFactory, you generate a fully Swagger-documented REST API to connect virtually any database or service in minutes.
DreamFactory 4.8.0 has been released! This release focuses on user experience, notably with regards to database API generation. The most popular database connectors (MySQL, MariaDB, PostgreSQL, MS SQL Server, and Oracle) have long included a lengthy list of options, and it hasn’t been obvious which are required and which are optional. To remedy this we’ve broken the service creation form into three sections: Basic, Caching, and Optional Advanced Settings. Additionally, because the Services tab is the natural first tab new users should be clicking on after logging in, we’ve moved the tab to the second position in the navigational bar directly following the Home tab.
In upcoming releases users will see a stream of additional UX improvements intended to more effectively guide new users through the API generation process. Notably, for most basic use cases the administrator completes three tasks: generate the API, create a role-based access control (RBAC), and then associate the RBAC with a newly generated API key. Therefore after successful API generation users will be presented with a new view enumerating typical next steps. We’re also working on improving the service profile detail page, providing admins with a link list taking them directly to the service’s relevant other administrative features, such as API Docs and associated roles.
Want to learn more about DreamFactory? Sign up for a free hosted trial now!
Join the DreamFactory newsletter list.