Introduction to gRpc

gRPC is a modern open-source high-performance Generic Remote Procedure Call framework that can run in any environment.

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.

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 Benefits:

• gRPC offers a refreshed take on the old RPC design method by making it interoperable, modern, and efficient using such technologies as Protocol Buffers and HTTP/2. The following benefits make it a solid candidate for replacing REST in some operations.
• Lightweight messages. Depending on the type of call, gRPC-specific messages can be up to 30 percent smaller in size than JSON messages.
• High performance. By different evaluations, gRPC is faster than REST+JSON communication.
• Built-in code generation. gRPC has automated code generation in different programming languages including Java, C++, Python, Go, Dart, Objective-C, Ruby, and more.
• More connection options. While REST focuses on request-response architecture, gRPC provides support for data streaming with event-driven architectures: server-side streaming, client-side streaming, and bidirectional streaming.

GRPC Concepts:

gRPC owes its success to the employment of two techniques: using HTTP/2 instead of HTTP/1.1 and protocol buffers as an alternative to XML and JSON. Most of the gRPC benefits stem from using these technologies.

Protocol Buffers for defining schema:

Protocol buffers are a popular technology for structuring messages developed and used in nearly all inter-machine communication at Google. In gRPC, protocol buffers (or protobufs) are used instead of XML or JSON in REST.

gRPC services and messages between clients and servers are defined in proto files. The Protobuf compiler, protoc, generate 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.

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.

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:

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 Weakness:

• Limited Browser Support
• No Edge Caching
• Not human-readable format-By compressing data to a binary format, protobuf files become non-human readable.

gRPC vs REST:

Both REST and gRPC have their place in the IT landscape.

In terms of ease of use, REST wins hands down. When developers use a REST API, it’s essentially the same as calling a webpage. To create a REST API, the only tool developers need is an integrated development environment in which they create and launch a web server.

However, REST is bulky and stateless. A REST response sends a lot of data over the network, and most of it has to do with data structure instead of the actual data itself.

In REST, developers can’t create a connection to a target and then have the target continuously return data over that connection. Developers must periodically make a call to the API to get that data.

On the other hand, gRPC is designed to support continuous streaming. It uses the HTTP/2 protocol, which has streaming support built in. With HTTP/2, developers can establish a connection to a gRPC-enabled server and then have that server continuously send serialized data in Protocol Buffers back to the client.

The downside of gRPC is that developers need to know a lot of concepts and operations to use it. For example, both the client and the server need to know the .proto file specification. Both use that information to perform encoding and decoding with Protocol Buffers. Unlike REST, developers can’t execute a call by entering a URL in a tool and receive back a result in JSON.

There’s a lot of encoding and decoding that needs to happen on both the client and server to work with the Protocol Buffers serialization. This encoding and decoding consumes computing resources but results in a lightning-fast data exchange. Understand that you’ll need to do a lot more work to make that data meaningful for consumption, whereas under REST, what you see is what you get.

‍Do I need to Switch from REST?

gRPC is not the evolution of REST, nor is it a better way to build APIs. In a nutshell, it is a way to use RPC’s lightweight structure along with HTTP with a few handy tweaks. It’s just another alternative for you to consider when you start designing a new API.

References: https://opensource.google/projects/grpc