¿Debería utilizar gRPC en lugar de REST?

Should I use gRPC instead of REST?

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.

“gRPC is roughly 7 times faster than REST when receiving data & roughly 10 times faster than REST when sending data for this specific payload. This is mainly due to the tight packing of the Protocol Buffers and the use of HTTP/2 by gRPC.”

When to use gRPC

1. Real-time communication services where you deal with streaming calls.
2. When efficient communication is a goal.
3. In multi-language environments.
4. For internal APIs where you don’t have to force technology choices on clients.
5. New builds as part of transforming the existing RPC API might not be worth it.

gRPC is the modern, lightweight communication protocol from Google. gRPC is a high-performance, open source, universal RPC framework that can run in any environment. The g in gRPC does not stand for Google. It is a recursive acronym that stands for grpc remote procedure call.

gRPC is a high-performance, open source, universal RPC framework that can run in any environment. The g in gRPC does not stand for Google. It is a recursive acronym that stands for grpc remote procedure call. gRPC originated from Google in 2015.

Today, a huge part of the internal service-to-service communication at Netflix runs on gRPC. “The adoption has been a success and continues to move forward, especially in the Java space,” says Bozarth. All new Java development starts with a gRPC-enabled application.

You can use protobuf inside any program, that has no need to be client/server. If you need to exchange data, and want them to be strongly typed, protobuf is a nice option (fast & reliable).

Fortunately, gRPC is encoding agnostic! You can still get a lot of the benefits of gRPC without using Protobuf. Additionally, we are going to be using our own encoding too. Gson allows us to bring our own types in our code, but provides a way of serializing those types into bytes.

Second, gRPC uses Protocol buffer to serialize payload data, which is binary and smaller, while REST uses JSON, which is text and larger. The API contract in gRPC is strict, and required to be clearly defined in the proto file. While in REST, it’s often loose and optional.

First, gRPC uses HTTP/2 which is, as you know, much faster than HTTP/1.1 used in REST by default. Note that today we can enable HTTP/2 in REST as well, but normally it often goes with HTTP/1.1.

Despite the benefits in message transmission speed, gRPC API implementation is a great deal slower than REST API implementation. According to Ruan Fernando, it takes approximately 45 minutes to implement a simple gRPC Service. It only takes about 10 minutes to implement a Web or REST API.

Finally, gRPC is faster, in part because Google’s “protocol buffer” data structures take up less space than the JSON packets RESTful APIs rely on. How do gRPC and REST compare to competitors?