Omer Faruk Kurular wrote:Hi,
Do you think that the role of the gRPC in the market will be more dominant over REST in the future?
gRPC is already being used as the preferred choice for inter-service communication. gRPC is far superior in performance as compared to REST. Therefore, microservices-based systems mostly use gRPC.
On the web (UI->Backend), REST is still the preferred choice. Recently, gRPC started supporting the web. GraphQL is a more popular choice nowadays and has more probability to replace REST from the top position.
Stephan van Hulst wrote:What data is there to support the statement that gRPC has superior performance compared to REST?
As far as I am aware, REST is just a set of design principles, and not a specific technology.
I believe the performance difference comes from that rest communications is based on JSON and gRPC is based on Protobuf which is more lightweight than json. It turns out that grpc is 7 to 10 times faster than REST.
REST is built on top of HTTP. Therefore, it involves extra processing for parsing. You can pass data as a query string, headers, or body. Then, you can have data as plain text, JSON or XML. All data types need to serialize and deserialize.
There is no parsing overhead in gRPC and protobuf contains binary data.
REST is also not built on top of HTTP. Its design was inspired by the HTTP protocol, but you can have a RESTful hypermedia system without using HTTP or JSON.
Even if a RESTful service is accessed through HTTP, I find it strange to state that it incurs a performance penalty because the HTTP must be parsed, while at the same time stating that gRPC incurs no such cost, even though it uses HTTP/2.
At the end of the day, REST is a set of design guidelines, while gRPC is a very specific technology. You can't compare the two.
Check your pockets for water buffalo. You might need to use this tiny ad until locate a water buffalo: