gRPC - The Framework for the future

Application programming interfaces — more commonly known as APIs — are at the heart of the most successful digital companies. Several organizations, from tech giants to startups, owe their business development to APIs. Acting as a communication medium between systems, APIs make a range of web products and mobile apps accessible to millions of users across the Internet. So, choosing the right technology to provide an API for your app is crucial. REST API has dominated the market for many years, and it uses HTTP/1 as its underlying transport protocol. This article introduces you to gRPC, which uses HTTP/2 as its underlying transport protocol. It provides better features, performance, and security over HTTP/1. Let’s explore gRPC which promises to solve issues other design styles weren’t fully able to.

What is gRPC?

gRPC is an open-source high-performance RPC (Remote Procedure Call) technology for implementing RPC APIs that uses HTTP/2 as its underlying transport protocol. At the application level, gRPC streamlines messaging between clients and back-end services. When compared to the REST+JSON combination, gRPC offers better performance. And it heavily recommends the use of SSL/TLS to authenticate the server and encrypt all the data exchanged between the client and the server.

How gRPC Works?

Like many RPC systems, gRPC is based on the idea of defining a service and specifying the methods that can be called remotely with their parameters and return types. Similarly, like Rest uses JSON/XML as the Interface Definition Language (IDL), gRPC uses Protocol Buffers by default for describing both the service interface and the structure of the payload messages.

In gRPC, a client application can directly call methods on a server application on a different machine as if it was a local object, making it easier to create distributed applications and services.

gRPC clients and servers can run and talk to each other in a variety of environments and can be written in any of gRPC’s supported languages, such as server written in Java with clients in Go, Python, or Ruby.

gRPC Strengths

1. Performance

   gRPC is much faster than REST. To validate this...
   
   The test program is written using GO lang. The client has 10 threads, which will send a large-size message with a name string and an array with10K integers, and each thread will repeat 5000 times for sending the message. The Cloud Run service is defined as 1 instance 1 CPU with concurrency = 10. The result is shown as follows
   
   
   
   The gRPC throughput is 48 requests per sec which is > 10X than REST API. It uses much less CPU time to process each message ( cpu time ms / req per sec = 832 / 48 = 17.33ms) when compared to REST (404 ms / 4 = 101 ms). The request latency is similar - 6ms and 8ms, respectively.
   
   As gRPC messages are serialized using Protobuf, an efficient binary message format. Protobuf serializes very quickly on the server and client. Protobuf serialization results in small message payloads, along with this it uses HTTP/2 protocol which helps it to scale the performance ranking via server push, multiplexing, and header compression.

2. Streaming

   Streaming is one of the core concepts of gRPC where several things can happen in a single request. This is made possible by the multiplexing capability of HTTP/2.
   
   There are several types of streaming:
   • Unary (no streaming)
     • Unary is a simple request and response model similar to REST, where the client sends one request to the server and gets one response back, the same as with a normal function call.
   • Client-side streaming
     • In this, the client sends a series of messages to the server and waits for the server response. Here, gRPC guarantees message ordering within an individual RPC call.
   • Server-side streaming
     • In the server-side streaming, the client sends a single request and in return, the server sends a stream of messages
   • Bi-directional streaming
     • Both sides send a sequence of messages via a read-write stream. The two streams work independently of each other and, as such, the clients and servers can read and write in any order. For instance, the server reads a message then writes a response. Or the server waits to receive all the client messages before writing its responses. gRPC preserves the order of messages in each stream

3. Code Generation

   The prime feature of gRPC methodology is the native code generation for client/server applications. A core file to gRPC development is the. proto file, which defines the contract of gRPC services and messages. From this file, gRPC frameworks generate a service base class, messages, and a complete client. It can produce server-side skeletons and client-side network stubs, which saves significant development time in applications with various services.

4. Interoperability

   gRPC allows for describing a service contract in a binary format, programmers can have a standard way to specify those contracts independent of any language, and that ensures interoperability.

5. 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.

6. Built-in Features

   gRPC provides built-in support for encryption, authentication, tracing, timeouts, interceptors, load balancing, and service discovery.
   
   

Weaknesses of gRPC?

Limited browser support

gRPC has excellent cross-platform support! gRPC implementations are available for every programming language in common usage today. However, one place you can’t call a gRPC service from, is a browser. gRPC heavily uses HTTP/2 features and no browser provides the level of control required over web requests to support a gRPC client. So, you need to use a proxy, which has its limitations. There are currently two implementations of the gRPC-Web client. Not all of gRPC’s features are supported by gRPC-Web. Client and bidirectional streaming aren’t supported, and there is limited support for server streaming.

Not human readable

HTTP API requests using JSON are sent as text and can be read and created by humans.

gRPC messages are encoded with Protobuf by default. While Protobuf is efficient to send and receive, its binary format isn’t human readable. Protobuf requires the message’s interface description specified in the .proto file to properly deserialize. Additional tooling is required to analyze Protobuf payloads on the wire and to compose requests by hand.

gRPC recommended Use Cases

gRPC is well suited to the following use cases:

• Microservices – gRPC is designed for low latency and high throughput communication. gRPC is great for lightweight microservices where efficiency is critical.
• Point-to-point real-time communication – gRPC has excellent support for bidirectional streaming. gRPC services can push messages in real-time without polling.
• Polyglot environments – gRPC tooling supports all popular development languages, making gRPC a good choice for multi-language environments.
• Network constrained environments – gRPC messages are serialized with Protobuf, a lightweight message format. A gRPC message is always smaller than an equivalent JSON message.

Conclusion

gRPC is a powerful new tool, which has a growing community and support from Google and CNCF. While gRPC is not a complete replacement for HTTP APIs, it offers improved productivity and performance benefits in some scenarios such as microservice communication, real time communication etc.

References

1. https://grpc.io/
2. https://devblogs.microsoft.com/dotnet/grpc-vs-http-apis/
3. https://medium.com/analytics-vidhya/grpc-vs-rest-performance-comparison-1fe5fb14a01c
   
   

About Encora

Fast-growing tech companies partner with Encora to outsource product development and drive growth. Contact us to learn more about our software engineering capabilities.