GRPC VS REST

🔸GRPC:

GRPC (gRPC Remote Procedure Call) is a high-performance, language-agnostic framework for building remote services. It uses Protocol Buffers (protobuf) as the interface definition language and binary serialization format. It uses HTTP/2 as its underlying protocol, which provides features like bidirectional streaming, header compression, multiplexing, and more. It's designed for high-performance, low- latency communication between clients and servers.

🔸Streaming is one of the core concepts of gRPC where several things can happen in a single request. This is made possible by the multiplexing capability of HTTP/2 .

Server Streaming RPC: Where the client sends a single request and the server can send back multiple responses. For example, when a client sends a request for a homepage that has a list of multiple items, the server can send back responses separately, enabling the client to use lazy loading.

Client Streaming RPC: Where the client sends multiple requests and the server only sends back a single response. For example, a zip/chunk uploaded by the client.

Bidirectional Streaming RPC: Where both the client and server send messages to each other at the same time without waiting for a response.

🔸REST

It typically uses HTTP/1.1 or HTTP/2 for communication.

While HTTP/2 can offer some improvements over HTTP/1.1, REST APIs.

Table

GRPC	Rest
gRPC: It uses Protocol Buffers (protobuf) as its default serialization format. Protocol Buffers offer efficient serialization, smaller message sizes, and better performance compared to JSON used in REST APIs.	-It commonly uses JSON (JavaScript Object Notation) for data serialization, which is human-readable and widely supported but can be less efficient in terms of size and processing compared to Protocol Buffers.
It commonly uses JSON (JavaScript Object Notation) for data serialization, which is human-readable and widely supported but can be less efficient in terms of size and processing compared to Protocol Buffers.	It typically relies on HTTP methods (GET, POST, PUT, DELETE, etc.) and URL paths to define resources and actions. The OpenAPI Specification (formerly known as Swagger) is commonly used to document REST APIs.
It has official support for multiple programming languages, including but not limited to, Java, Python, Go, C++, etc. Generated client libraries can provide type-safe access to remote services.	Since it relies on standard HTTP protocols, REST APIs can be consumed by virtually any programming language or platform with HTTP support.
It is well-suited for scenarios requiring high-performance, streaming, and low-latency communication, such as microservices architectures, IoT, and real-time applications..	It is more suitable for scenarios where simplicity, flexibility, and compatibility with existing systems are important, such as web applications, public APIs, and integrations with third-party services.

Downsides of GRPC:

✅Limited Browser Support As gRPC heavily uses HTTP/2, it is impossible to call a gRPC service from a web browser directly. No modern browser provides the control needed over web requests to support a gRPC client. Therefore, a proxy layer and gRPC-web are required to perform conversions between HTTP/1.1 and HTTP/2.

✅Non-human Readable Format Protobuf compresses gRPC messages into a non-human readable format. This compiler needs the message’s interface description in the file to deserialize correctly. So, developers need additional tools like the gRPC command-line tool to analyze Protobuf payloads on the wire, write manual requests, and perform debugging.