What is gRPC?

gRPC is an open-source RPC framework that is used for high-performance communication between services. It is an efficient way to connect services written in different languages with pluggable support for load balancing, tracing, health checking, and authentication. By default, gRPC uses protocol buffers for serializing structured data. Generally, gRPC is considered as a better alternative to the REST protocol for microservice architecture. The "g" in gRPC can be attributed to Google, who initially developed the technology.

The most important difference with traditional RPC is that gRPC uses protocol buffers as the interface definition language (IDL) for serialization and communication instead of JSON/XML. Protocol buffers can describe the structure of data and the code can be generated from that description for generating or parsing a stream of bytes that represents the structured data.

This is the reason gRPC is preferred for the web applications that are polyglot (implemented with different technologies). The binary data format allows the communication to be lighter.

Also, gRPC is built on top of HTTP/2, which supports bidirectional communication along with the traditional request/response. gRPC allows a loose coupling between server and client. The client opens a long-lived connection with the gRPC server and a new HTTP/2 stream will be opened for each RPC call.

REST Architecture

REST (REpresentational State Transfer) is a web architecture that uses HTTP protocol. It is widely used for the development of web applications. REST is a client-server model where backend data is made available via simple representations like JSON/XML to the client. REST is a protocol that does not enforce any rules about how it should be implemented at a lower level. It provides guidelines for high-level architecture implementation.

In order to make any application truly RESTful, six architectural constraints must be followed:

1. Uniform interface: Meaning API interfaces must be present to the resources in the web application to the consumers of the API.
2. Client-server: The client and server must be independent of each other, and the client should only know the URIs to the resource.
3. Stateless: The server must not store anything related to the client request. The client is responsible for maintaining the state of the application.
4. Cacheable: The resources must be cacheable.
5. Layered system: The architecture must be layered, meaning the components of the architecture can be in multiple servers.