What is gRPC? The charastaristics compared with REST, GraphQL

What is gRPC

gRPC is an open source Remote Procedure Call (RPC) framework developed by Google

(Ref: https://grpc.io)

for more details, gRPC Motivation and Design Principles and Core concepts, architecture and lifecycle

Characteristics

Let's take a look at some charactaristics of gRPC from several perspectives

1. Developent flow

1. Create proto file
2. Execute protoc and automatically generate source code from the proto file created in 1.
3. Implementation
   • On the server side, an interface compiled and corresponding to the service definition in the proto file is prepared, so we implement this interface.
   • On the client side, since the part of communication with the server is automatically generated and implemented, RPC can be realized simply by creating a connection, specifying parameters, and invoking the communication process.

2. Technological evolution(HTTP/2)

Multiplxing idependent streaming

This makes possible to handle multiple requests and responses simultaneously over the same TCP connection.
gRPC minimizes network round trips and reduces request latency. This is especially beneficial for communication between microservices and in latency-critical applications.

Unary RPC

Server Streaming RPC

Send stream from Server to Client.
e.g.) Push notification from Server to Client, Periodic acquisition of information

Client Streaming RPC

Send stream from Client to Server.
e.g.) Multi-part upload of files

Bi-Directional Streaming RPC

Send streams in both directions.
e.g.) Chat rooms via a server

Header compression

This also improves gRPC performance and efficiency, providing gRPC with the benefits of higher bandwidth usage and improved latency.

Binary data format

gRPC uses an efficient binary format called Protocol Buffers for data exchange.
This improve performance of transferring data, serialization and deserialization.

3. Comparison with other frameworks(REST, GraphQL) by several viewpoints

Transferred data

• REST:
  • JSON, HTML, XML
• GraphQL:
  • JSON
• gRPC:
  • Protocol Buffers
• (SOAP: XML)

Assumed protocol underneath

• REST:
  • HTTP/1.1
• GraphQL:
  • HTTP/1.1
• gRPC:
  • HTTP/2

Performance in comparison with REST

• REST:
  • This is versatile so the performance varies dependent on the usage.
• GraphQL:
  • Faster than REST in some cases because the clients can specify the exact data structure needed and request only the data they need, thus reducing excessive data fetching.
• gRPC:
  • Fastest(low latency and high throughput) of three frameworks in the case where parallel and highhigh-intensity requetes are executed because it make use of the efficient streaming and multiplexing features of HTTP/2.

Flexibility of data fetching

• REST:
  • Flexible in terms of client diversity. It is compatible to work for many clients.
    • ex) serverside application, web browser, mobile application, IoT devise, many third party applications.
  • But resources to be fetched in a API is fixed.
• GraphQL:
  • Flexible in terms of data responded at once because it can customize queries to fetch resources. It helps us manipulate multiple resources or manipulate only the resources we need at once.
• gRPC:
  • Flexible in terms of streaming features.
    • As we saw above, it can conduct 4 streaming features.
  • But in terms of granularity of resources or compatible client, it's not flexible. Rather we can say it is robust. With protobuf, APIs are defined in a structured, schema-like format, facilitating clear and consistent communication between services. This structure mandates strict data types and request/response patterns, reducing ambiguity and enhancing type safety in communications.

4. Pros & Cons

Pros

• gRPC makes it possible to communicate with servers with any language as long as that language supports gRPC

• API definitions are determined by protobufs, making it very easy to develop the client and server in parallel.

  • May the point is similar to OpenAPI and Swagger, but the actual implementation is not always follow the specification. Which means the implementation is dependent on the developer.

• In most cases gRPC official libraries are used so that API is automatically generated according to the protobuf, so there is no deviation from the definition unless the proto is changed.

• Faster than to HTTP/1.1 in most cases.

Cons

• Debugging is a bit tricky. The data is serialized in binary so that we cannot read it.

  • It is possible to debug like that with grpcurl (ref).
    • However, the server must have reflection enabled and the protobuf information must be public.
    • If we do this in production, API information will be leaked.

• Some services and languages still don't support gRPC.

• HTTP/2, so load balancing techniques are more difficult than HTTP/1.1.

5. Suitable & Unsuitable usecase

Suitable

gRPC is suitable under the below requirements

• Schema first development
• High reliability(robust)
• High performance
• Parallel requests
• High-intensity requests

ex) Microservice

Unsuitable?

gRPC is NOT suitable under the below situation

• Client have advantage of JSON over protobuf
  • ex) SPA
• Clients requests via public internet
  • ex) Web, iOS, Android server from which actual user request
  • because a concern with the routes of request may be the performance bottleneck rather than the performance increase by gRPC.