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.
Actually, gRPC is also a set of libraries that provide higher-level features across platforms that common HTTP libraries typically do not.
- 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
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.
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
.d.ts files in the structure required by grpc-web. Let’s generate our TypeScript definitions now using protoc by executing the following command:
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:
- 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.
- Not human-readable format. After compressing data to a binary format, protobuf files become non-human readable, unlike XML and JSON. To analyze payloads, perform debugging, and write manual requests, devs must use extra tools.
- High entry threshold. Compared to REST which primarily use JSON, it will take some time to start working with protocol buffers and find tools for dealing with HTTP/2 protocol.
- Limited Browser Support. Because 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.
- Still does not have integrations with popular FE frameworks (React, Angular, Vue).
I hope this provides the information you would need to gets started using gRPC in your Angular applications, or at least provides you with the information you need to know whether it’s right for your needs.