The popular client-server architecture divides communication into two parts: one that takes up all heavy tasks and provides services, known as the server, and the other one that enjoys those services, known as the client.
In general client-server communication, the client simply sends a request asking for resources or services to the server, and the server responds to that request.
For client-server communication, clients and servers need to have libraries that can understand the protocol in which they are communicating. A protocol is a language or set of internet communication rules. They are transport mechanisms that follow some guidelines for transporting data over the internet.
The second most important aspect of client communication is the message format on which both the client and server can agree. This message format is based on some schemas, and by not following these schemas, communication wouldn’t be taking place. Message formats can be similar to XML, which adheres to a schema, or a JSON file, which must contain specific key-value pairs.
Another important aspect of this type of communication to understand is that it is based on a request and response mechanism, which means that the server only communicates when the client initiates the communication. With REST and GraphQL, this is mostly unidirectional. This is a basic problem that will be solved by technology like gRPC.
In the early ’90s, a popular client-server protocol called SOAP used XML message format with a hardcoded schema. The schema for the message format was very rigid. Lack of freedom is what caused the abandonment of SOAP and the emergence of REST.
In simple words, Rest is a guideline for transferring JSON messages over the internet with HTTP as its protocol (transport mechanism). With Rest, one doesn’t need to worry about making a schema.
We talked about the emergence of REST. Now let’s deep dive into its core technology. So let me tell you that REST stands for Representational State Transfer. Rest is a standardized software architectural style, an API used a lot in the industry.
Imagine you are making a website for a restaurant. You have all the menus online, and food items are divided into three categories:
Now, let’s say you want to see all the beverages online. In the Rest architecture, you can easily and consistently partition all of your resources on API endpoints. Of course, you can use multiple authentications on them to make them secure.
In this type of case, we send a GET request to the server to an endpoint where we can get beverage resource data.
Similarly, we can perform all CRUD (Create, Read, Update, Delete) in the Rest API, which makes it suitable for big projects that don’t require super-transfer of data and do not need to be real-time.
Rest works best for projects where the efficient transfer of data is an important factor. Caching is another feature of REST that is useful for standard applications like food booking apps, hotel booking apps, blog websites, online forum websites, etc.
REST is great, but it has many cons that are quite crucial in some cases. Let’s talk about them.
To tackle the first problem with REST, which is the need for bi-directional communication, WebSocket was invented, which permits the server to initiate the communication, but the problem with it is that it doesn’t have the format. It just sends bytes and has no restrictions.
The Websockets didn’t have any problems of their own, but the actual issue is that any type of communication requires a protocol, and each protocol requires a client library that can communicate using that protocol.
If you are creating a Python application that works on the Rest architecture, you will need an HTTP client that can communicate with the server. In many cases, client libraries are made by a third party, mainly an independent developer. Using third-party libraries can expose your security, and your entire application will depend on a third party for communication.
In the case of a web application, the browser acts like a client library, but for non-web projects, you will need a third-party client library. If you are thinking of making one on your own, then remember that it is not that easy, and you will burden yourself with maintaining another application.
So, to tackle some problems with Rest and to tackle problems with client libraries, Google invented gRPC in 2015.
For gRPC, one client library is maintained by Google for almost all popular languages. It uses the HTTP 2 protocol under the hood and protocol buffer (protobuf) as its message format.
You don’t need to worry about any client library as Google is maintaining it for you and almost every programming language. A single and centralized client library is one of the major strengths of gRPC.
Another benefit of gRPC is the message format that it uses. The protocol buffer is language agnostic, so you can make clients in Python and servers in Go and still be able to communicate without making any fuss.
gRPC is essentially one client library and one protocol that can be used on any device.
gRPC uses protobuf to communicate. It serializes proto files into binary format and sends them to the server, and on the server side, they are deserialized into the original format. That’s how it works with protobuf.
gRPC has different forms of communication. You can think of them as features of gRPC.
These are four popular features of gRPC that make it so powerful.
As for the features of gRPC, we saw some use cases for gRPC. Let’s imagine you want to make a chat application. You are not going to use the Rest API as it will not be able to allow fast streaming of bi-directional communication. For this, we will be using the gRPC stream, which will provide some more benefits other than speed.
First, its language-neutral behavior doesn’t matter in what programming language the server or other clients are writing. Communication can still be established until the message format is accepted.
So, with this feature, the Android version of the chat app can communicate with the iOS version and vice versa.
There are issues with everything, including gRPC.
Now we will discuss the technical difference between REST and gRPC.
The message format used by REST is mostly JSON (sometimes XML format), which is a more readable form and easier to handle. You will not have to worry about the schema in Rest. On the other hand, gRPC uses a protocol buffer to serialize data. The compressed form is lighter and faster to travel with. It is in binary format, so it serializes and deserializes data to transmit it.
HTTP 1.1 vs. HTTP 2:
The Rest API usually uses HTTP 1.1 as its protocol, whereas gRPC uses HTTP 2 as its protocol underhood. The Rest API can still use HTTP 2 but is still limited because of the request-response mechanism. gRPC uses HTTP 2 and takes advantage of HTTP 2 support for both client-response and bidirectional communication. This is another aspect that makes gRPC performance better than REST. It can manage unidirectional requests like HTTP 1.1 and bidirectional requests simultaneously like HTTP 2.
gRPC’s low latency and high speed in communication make it useful for connecting to systems that consist of lightweight microservices architecture, which increases message transmission efficiency. In most cases of the network, latency REST takes 25ms, whereas gRPC latency is far less than REST.
Rest has a maximum payload limit of 45MB when sending outgoing messages, whereas gRPC doesn’t have any limit, meaning your outgoing message can be as heavy as you want.
In terms of security, Rest will lag as it uses HTTP 1.1 and JSON format, which is easy to decrypt and access. On the other hand, gRPC uses HTTP 2, which is far more secure, and uses protobuf, which is in binary format and hard to decrypt.
Here again, gRPC wins, as it offers 10x more speed than Rest, and it is for the same reason, using HTTP 2 as the protocol and protobuf as the message format.
The code generation function
Rest does not provide built-in code generation features, meaning the developer needs third-party apps to produce API code, whereas gRPC has native code generation features due to its protobuf compiler, which is compatible with several programming languages. This is another benefit, particularly for microservice architectures.
To enable message production via HTTP calls for various use cases and ease of use, Memphis added an HTTP gateway to receive REST-based requests (=messages) and produce those messages to the required station.
Common use cases that benefit from the REST Gateway are:
Memphis REST Gateway + a JSON schema can be a powerful combination to increase data quality and ensure healthy communication between applications or services.
Memphis will soon support gRPC as well.
Read more here
Ultimately, I would like to say that REST is still the most used and popular architecture, and it is impossible to abandon. REST has many cons, like lack of data streaming, no bi-directional communication, slow speed, etc., but it is best for standard applications that we see in daily life.
On the other hand, gRPC, being young and tough to learn, provides many things like high data streaming on both the client and server side, good bi-directional data streaming, is fast and compact, and uses HTTP 2. Due to its fast performance, gRPC is best suited for high-workload applications like video streaming, song streaming, online gaming, file sharing, and chat applications.