What is gRPC? Meaning, Architecture, Advantages

gRPC meaning

gRPC is a robust open-source RPC (Remote Procedure Call) framework used to build scalable and fast APIs. It allows the client and server applications to communicate transparently and develop connected systems. Many leading tech firms have adopted gRPC, such as Google, Netflix, Square, IBM, Cisco, & Dropbox. This framework relies on HTTP/2, protocol buffers, and other modern technology stacks to ensure maximum API security, performance, and scalability.

History of the gRPC

In 2015, Google developed gRPC as an extension of the RPC framework to link many microservices created with different technologies. Initially, it was closely associated with Google’s internal infrastructure, but later, it was made open-source and standardized for community use. During the first year of its release, it was leveraged by top organizations to power use cases from microservices to web, mobile, and IoT. And in 2017, it became the Cloud Native Computing Foundation (CNCF) incubation project due to its increasing popularity.

‍

Basic gRPC Concepts

gRPC owes its development and success to the use of the leading technologies that perform better than JSON and XML and provide increased API security. Most of the gRPC advantages stem from the following concepts:

Protocol Buffers

Protocol buffers, or Protobuf, is Google’s serialization/deserialization protocol that enables the easy definition of services and auto-generation of client libraries. gRPC uses this protocol as their Interface Definition Language (IDL) and serialization toolset. Its current version is proto3, which has the latest features and is easier to use.

gRPC services and messages between clients and servers are defined in proto files. The Protobuf compiler, protoc, generates client and server code that loads the .proto file into the memory at runtime and uses the in-memory schema to serialize/deserialize the binary message. After code generation, each message is exchanged between the client and remote service.

The entire flow shows that Protobuf offers some great benefits over JSON and XML. Parsing with Protobuf requires fewer CPU resources since data is converted into a binary format, and encoded messages are lighter in size. So, messages are exchanged faster, even in machines with a slower CPU, such as mobile devices.

Streaming

Streaming is another key concept of gRPC, where many processes can take place in a single request. The multiplexing capability (sending multiple responses or receiving multiple requests together over a single TCP connection) of HTTP/2 makes it possible. Here are the main types of streaming:

• Server-streaming RPCs – The client sends a single request to the server and receives back a stream of data sequences. The sequence is preserved, and server messages continuously stream until there are no messages left.
• Client-streaming RPCs – The client sends a stream of data sequences to the server, which then processes and returns a single response to the client. Once again, gRPC guarantees message sequencing within an independent RPC call.
• Bidirectional-streaming RPCs – It is two-way streaming where both client and server sends a sequence of messages to each other. Both streams operate independently; thus, they can transmit messages in any sequence. The sequence of messages in each stream is preserved.

HTTP/2

gRPC is developed on HTTP/2, which was published in 2015 to overcome the HTTP/1.1 limitations. While it is compatible with HTTP/1.1, HTTP/2 brings many advanced capabilities, such as:

• Binary Framing Layer – Unlike HTTP/1.1, HTTP/2 request/response is divided into small messages and framed in binary format, making message transmission efficient. With binary framing, the HTTP/2 protocol has made request/response multiplexing possible without blocking network resources.
• Streaming – Bidirectional full-duplex streaming in which the client can request and the server can respond simultaneously.
• Flow Control – Flow control mechanism is used in HTTP/2, enabling detailed control of memory used to buffer in-flight messages.
• Header Compression – Everything in HTTP/2, including headers, is encoded before sending, significantly improving overall performance. Using the HPACK compression method, HTTP/2 only shares the value different from the previous HTTP header packets.
• Processing – With HTTP/2, gRPC supports both synchronous and asynchronous processing, which can be used to perform different types of interaction and streaming RPCs.

All these features of HTTP/2 enable gRPC to use fewer resources, resulting in reduced response times between apps and services running in the cloud and longer battery life for a client running mobile devices.

Channels

Channels are a core concept in gRPC. The HTTP/2 streams allow many simultaneous streams on one connection; channels extend this concept by supporting multiple streams over multiple concurrent connections. They provide a way to connect to the gRPC server on a specified address and port and are used in creating a client stub.

‍

gRPC Architecture

In the following gRPC architecture diagram, we have the gRPC client and server sides. In gRPC, every client service includes a stub (auto-generated files), similar to an interface containing the current remote procedures. The gRPC client makes the local procedure call to the stub with parameters to be sent to the server. The client stub then serializes the parameters with the marshaling process using Protobuf and forwards the request to the local client-time library in the local machine.

The OS makes a call to the remote server machine via HTTP/2 protocol. The server’s OS receives the packets and calls the server stub procedure, which decodes the received parameters and executes the respective procedure invocation using Protobuf. The server stub then sends back the encoded response to the client transport layer. The client stub gets back the result message and unpacks the returned parameters, and the execution returns to the caller.

‍

gRPC Advantages

gRPC provides a new take on the old RPC design method by offering many benefits in certain operations. Some of the gRPC strengths which have been increasing its adoption are as follows:

1. Performance

By different evaluations, gRPC offers up to 10x faster performance and API-security than REST+JSON communication as it uses Protobuf and HTTP/2. Protobuf serializes the messages on the server and client sides quickly, resulting in small and compact message payloads. HTTP/2 scales up the performance ranking via server push, multiplexing, and header compression. Server push enables HTTP/2 to push content from server to client before getting requested, while multiplexing eliminates head-of-line blocking. HTTP/2 uses a more advanced compression method to make the messages smaller, resulting in faster loading.

2. Streaming

gRPC supports client- or server-side streaming semantics, which are already incorporated in the service definition. This makes it much simpler to build streaming services or clients. A gRPC service supports different streaming combinations through HTTP/2:

• Unary (no streaming)
• Client-to-server streaming
• Server-to-client streaming
• Bi-directional streaming

3. Code Generation

The prime feature of gRPC methodology is the native code generation for client/server applications. gRPC frameworks use protoc compiler to generate code from the .proto file. Code generation is used in command of the Protobuf format for defining both message formats and service endpoints. It can produce server-side skeletons and client-side network stubs, which saves significant development time in applications with various services.

4. Interoperability

gRPC tools and libraries are designed to work with multiple platforms and programming languages, including Java, JavaScript, Ruby, Python, Go, Dart, Objective-C, C#, and more. Due to the Protobuf binary wire format and efficient code generation for virtually all platforms, programmers can develop performant applications while still using full cross-platform support.

5. Security

The use of HTTP/2 over the TLS end-to-end encryption connection in gRPC ensures API security. gRPC encourages the use of SSL/TLS to authenticate and encrypts data exchanged between the client and server.

6. Usability and Productivity

As gRPC is an all-in-one RPC solution, it works seamlessly across various languages and platforms. Additionally, it features excellent tooling, with much of the required boilerplate code generated automatically. This saves considerable time and enables developers to focus more on business logic.

7. Built-in Commodity Features

gRPC provides built-in support for commodity features, such as metadata exchange, encryption, authentication, deadline/timeouts and cancellations, interceptors, load balancing, service discovery, and so much more.

‍

gRPC Disadvantages

As with every other technology, gRPC also has the following downsides that you need to be aware of when choosing it for developing applications.

1. Limited Browser Support

As gRPC heavily uses HTTP/2, it is impossible to call a gRPC service from a web browser directly. No modern browser provides the control needed over web requests to support a gRPC client. Therefore, a proxy layer and gRPC-web are required to perform conversions between HTTP/1.1 and HTTP/2.

2. Non-human Readable Format

Protobuf compresses gRPC messages into a non-human readable format. This compiler needs the message’s interface description in the file to deserialize correctly. So, developers need additional tools like the gRPC command-line tool to analyze Protobuf payloads on the wire, write manual requests, and perform debugging.

3. No Edge Caching

While HTTP supports mediators for edge caching, gRPC calls use the POST method, which is a threat to API-security. The responses can’t be cached through intermediaries. Moreover, the gRPC specification doesn’t make any provisions and even indicates the wish for cache semantics between server and client.

4. Steeper Learning Curve

Many teams find gRPC challenging to learn, get familiar with Protobuf, and look for tools to deal with HTTP/2 friction. It is a common reason why users prefer to rely on REST for as long as possible.

gRPC versus REST

gRPC is a promising technology that has already gained a considerable footprint in the API area. However, it is neither a replacement of REST nor a better option to develop APIs. Basically, gRPC is another alternative that could be useful in certain circumstances: large-scale microservices connections, real-time communication, low-power, low-bandwidth systems, and multi-language environments.

Unlike REST, gRPC makes the most out of HTTP/2, with multiplexed streaming and binary protocol framing. In addition, it offers performance advantages through the Protobuf message structure and features built-in code generation capability, which enables a multilingual environment. All these features make gRPC a good API architectural style. However, one major downside of gRPC is low browser support, limiting it to internal systems.

In contrast, REST is supported by all browsers. Moreover, it has wider adoption and is an excellent choice for a company that wants to use a proven format. gRPC, on the other hand, is more structured and offers significant performance enhancements than REST. In conclusion, selecting the right API format for enterprise architecture is a major decision, highly dependent on your use-case demands.

Read more in articles: 

• gRPC vs REST
• What is REST / vs SOAP
• gRPC vs WebSocket

Conclusion

gRPC has gained a lot of traction over the years because it is fast and efficient, especially in microservices architecture. However, it presents a new set of security challenges – content validation, authentication, authorization, and much more – which must be addressed, made more difficult because the binary message format needs to be decoded for inspection. This means leveraging the OWASP API Security Top-10 to develop vulnerability and security risk detection & mitigation approaches for your gRPC applications. It also means applying a run-time API security layer with the ability to handle gRPC-specific scenarios without adding cost or complexity to your API security process.