Is gRPC(HTTP/2) faster than REST with HTTP/2?

Question

The goal is to introduce a transport and application layer protocol that is better in its latency and network throughput. Currently, the application uses REST with HTTP/1.1 and we experience high latency. I need to resolve this latency problem and I am open to using either gRPC(HTTP/2) or REST/HTTP2.

HTTP/2:

1. Multiplexed
2. Single TCP Connection
3. Binary instead of textual
4. Header compression
5. Server Push

I am aware of all the above advantages. Question No. 1: If I use REST with HTTP/2, I am sure, I will get a significant performance improvement when compared to REST with HTTP/1.1, but how does this compare with gRPC(HTTP/2)?

I am also aware that gRPC uses proto buffer, which is the best binary serialization technique for transmission of structured data on the wire. Proto buffer also helps in developing a language-agnostic approach. I agree with that and I can implement the same feature in REST using graphQL. But my concern is over serialization: Question No. 2: When HTTP/2 implements this binary feature, does use proto buffer gives an added advantage on top of HTTP/2?

Question No. 3: In terms of streaming, bi-directional use-cases, how does gRPC(HTTP/2) compare with (REST and HTTP/2)?

There are so many blogs/videos out on the internet that compares gRPC(HTTP/2) with (REST and HTTP/1.1) like this. As stated earlier, I would like to know the differences, benefits of comparing GRPC(HTTP/2) and (REST with HTTP/2).

Answer 1

GRPC	REST
gRPC can use protocol buffer for data serialization. This makes payloads faster, smaller and simpler.	As said earlier, REST supports cross-language interoperability which makes these web services flexible and scalable.
Just like REST, gRPC can be used cross-language which means that if you have written a web service in Golang, a Java written application can still use that web service, which makes gRPC web services very scalable.	REST is also widely used,  and many web services (and clients) use REST. Having a REST web service makes it easier for other people to interact with your web service.
gRPC uses HTTP/2 to support highly performant and scalable APIs and makes use of binary data rather than just text which makes the communication more compact and more efficient. gRPC makes better use of HTTP/2 then REST. gRPC, for example, makes it possible to turn-off message compression. This might be useful if you want to send an image that is already compressed. Compressing it again just takes up more time.	Communication often occurs using JSON, which is an open-standard file format that uses human-readable text to transmit data objects consisting of attribute-value pairs and array data types. This makes it easier for developers to determine if the client input is sent correctly to the server, and back.
It is also type-safe. This basically means that you can’t give an apple while a banana is expected. When the server expects an integer, gRPC won’t allow you to send a string because these are two different types.	But one of the main advantages of REST is that it does not need to set up a client. You just make a call to a server address (for example www.xyz.com). This even works if you just copy a REST server address (of a GET method) in your web browser. Other techniques, like gRPC, often require you to set up a client.