gRPC vs REST
Overview & Use Cases
REST is mentioned in REST API vs GraphQL, touching on its architecture (at a very high level), ease of implementation, and authentication + authorization. The use cases intended for REST compared to gRPC are what set them apart. REST is intended for:
- Web Services interfacing with clients across the internet (e.g. your browser).
- Very small number of back-end services interfacing with each other where performance is not critical (small-scale distributed system).
Whereas gRPC is intended to be used as:
- A very efficient protocol for communication between microservices in a distributed system.
This stark contrast is likely enough information for most users who are trying to decide between one or the other. However, for the curious, feel free to continue.
Note: Both REST and GraphQL are intended to be used in Web Services that interface with clients across the internet.
Table of Contents
Comparison
| REST | gRPC | |
|---|---|---|
| Underlying Protocols | HTTP/1.0 and higher (although 1.1 introduces HTTP methods OPTIONS, PUT, DELETE, and PATCH). | HTTP/2 (natively). HTTP/3 with additional tooling. |
| Data Format | Text-based (can be anything, but typically JSON or XML). | Typically Protocol Buffers (binary format). |
| Payload Size | Depends on many factors, such as server configs, client configs, proxy configs, etc. | Protobuf: 4MB by default (2GB hard limit) |
| Performance | Relatively slow performance due to unnecessarily large payload relative to the actual data being transmitted. | Relatively high performance for microservices relative to REST due to efficient encoding using binary format (but never as high as using monolith architecture to avoid network requests). |
| Human Readable | Yes, text-based. | gRPC does support text-based protocols, but Protocol Buffers are the standard (which are binary and not human-readable). |
| Streaming Support | Not natively supported. | Natively supported. |
| API Contract | Not defined. Requires third-party tools like Swagger for formal contract. | Strictly defined in `.proto` files. |
| Browser Support | Native support. | Not natively supported. |
| Interoperability | Very high, given that it's a text-based protocol. | Requires libraries written in the language. |
| Error Handling | HTTP status codes. | gRPC-specific error codes that can be extended. |
| Security | HTTPS | HTTPS |
| Load Balancing | Managed by HTTP infrastructure. | Natively supported (or via additional infrastructure). |
| Development Ecosystem | Mature | Growing |
Table template created by ChatGPT of OpenAI.
REST
As mentioned above, an overview of REST is provided in REST API vs GraphQL. Lack of technical aptitude is a primary reason to choose REST over GraphQL, given they predominantly share the same use case.
Although REST is text-based, it can be used over HTTP/2, which is a binary protocol. However, it doesn’t have the same efficient binary encoding as Protocol Buffers (which are typically used with gRPC, which itself runs on HTTP/2+).
gRPC
gRPC is an open-source framework developed by Google for efficient, high-performance inter-service communication. Protocol Buffers are used to create the Request and Response message schemas, as well as the client and server signatures (). gRPC provides libraries to convert these Protocol Buffer .proto files into language-specific libraries at Build Time that are imported into your project. These language-specific libraries facilitate RPCs between services.
Furthermore, gRPC provides streaming capabilities that REST does not. However, it’s important to note that it might make more sense to use a message broker (like Apache Kafka) over streaming. Learn more about gRPC vs Kafka.
Conclusion
If someone is building a large-scale distributed system (especially if using Kubernetes), gRPC is the way to go.
If someone is building communication between a web browser and Back-End system, then REST or GraphQL are the way to go.
If someone is building a small-scale distributed system, it depends on your level of technical aptitude.
Another helpful link is: gRPC vs REST - AWS
Updated: 2024-02-18
Author
Sam Malayek works in Vancouver, using this space to fill in a few gaps. Opinions are his own.