About gRPC

Google Remote Procedure Call (gRPC) is a modern, high-performance framework for APIs that evolves the age-old remote procedure call (RPC) protocol. At the application level, gRPC streamlines messaging between clients and back-end services.

gRPC was initially created by Google. It is open source under the Apache License 2.0 and part of the Cloud Native Computing Foundation (CNCF) ecosystem of cloud-native offerings. gRPC offers comprehensive support across most popular development stacks, including Java, JavaScript, C#, Go, Swift, and NodeJS. Version 1.0 was released in August 2016, and the current version is 1.48.1 as of the writing of this blog (see the most recent version here).

Actually, gRPC is also a set of libraries that provide higher-level features across platforms that common HTTP libraries typically do not. 

gRPC uses:

• HTTP/2 network protocol for transport.
• Protocol Buffers (protobuf) as the interface description language – is a data format used to serialize structured data. It can be up to 8x faster than JSON serialization with messages 60-80% smaller.
• support for sending multiple parallel requests over the same connection – when HTTP 1.1 limits processing to one request/response message at a time.

What is gRPC-Web

Modern browsers still do not fully support HTTP/2 protocol. There are no browser APIs with enough control over requests yet, so gRPC-Web (from Google) is a standardized plugin that solves this problem and makes gRPC usable in today’s browsers. gRPC-Web brings many of gRPC great features to current browser apps, lioke:

• small binary messages
• strongly typed, code-generated clients
• compact protobuf messages
• server streaming

Protocol Buffers

By default, gRPC uses Protocol Buffers as its interface description language. Google originally developed protobuf for internal use, but has subsequently provided code generators for multiple languages under an open-source license.

Using a cross-platform Interface Definition Language (IDL), developers define a service contract for each microservice. It provides platform-neutral serialization format for messages that services send to each other. Each message is serialized as a standard protobuf representation and exchanged between the client and remote service. Unlike JSON or XML, protobuf messages are serialized as compiled binary bytes.

Here is an example of a proto file:

As you can see, it’s just an ordinary text file with a .proto extension. Protocol buffer data is structured as messages, where each message is a small logical record of information containing a series of name-value pairs called fields. 

At the top of the file we define RPC service methods. For each method should be defined its request and response types.

The same contract file could be used for gRPC clients and services built on different development platforms.

PROTOC

To use the .proto file, you need to install the Protobuf compiler, protoc. It is used for the creation of auto-generated files from .proto files. After using this compiler, the .proto file will be serialized into a binary format which is compact, forward- and backward-compatible.

Binary gRPC messages are always smaller than an equivalent text-based JSON message, which is a major performance advantage of gRPC over REST APIs.

Because protoc doesn’t support TypeScript, we will need a plugin to help us generate a TypeScript service and client from the .proto file for our web applications. The plugin that does this for us is called ts-protoc-gen.

This plugin can also generate service definitions as either .js and .d.ts files in the structure required by grpc-web. Let’s generate our TypeScript definitions now using protoc by executing the following command:

For this to work in an Angular app, this command must be strictly executed in the root folder of your JavaScript app (at the same level as src folder). After this step you will get 4 files, 2 in JavaScript (services + client file and messages file) plus 2 in TypeScript (definition files).

Integration with Angular

The communication between you Angular web application and a gRPC API is a bit more complex than a simple request to a REST API. Below is code that retrieves TimeZone data with a unary RPC call*:

*NOTE: to make API calling you need to create a new Request() object. Then you add values to the request fields through the setParam methods. In Metadata, you can pass what we usually used to pass in headers when sending http requests (JWT-token for example).

To adhere to Angular best practices, it’s better to return Observable to subscribers after your gRPC call.

gRPC server does not response with the usual JSON of a REST API or even a string that can be converted to JSON. Field values must be obtained using methods like response.getToken(). Here is some code that reads data from a gRPC response:

gRPC Benefits

• Lightweight messages. Depending on the type of call, gRPC-messages can be up to 30 percent smaller in size than JSON messages thanks to their binary nature.
• High performance. By different evaluations, gRPC is from 5 to even 8 times 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 like server-side, client-side and in the future – bidirectional streaming.
• Is efficient in multi-language environments.

gRPC Weaknesses