First came the era of the monoliths, single-tiered software applications where the user interface, data access and business logic were baked into a single program from a single platform. As business requirements continued to evolve, microservices raised to prominence out of necessity. Out of the many ways you can interface two services, gRPC is my favourite.

Perhaps the most common way of connecting multiple services is by utilizing either an XML or JSON API using the HTTP/1 protocol. Lets compare the two behemoths.

gRPC vs HTTP APIs

HTTP APIs are the past, and the gRPC is the future.

Feature	gRPC	HTTP API
Contract	Required through .proto	Applicable for OpenAPI
Protocol	HTTP/2	HTTP/1
Payload	Binary	Text
Prescriptiveness	Strict	Loose
Streaming	Client, server, and bi-directional	Client, server
Security	TLS	TLS
Code geneeration	Yes	Applicable for OpenAPI

gRPC Advantages

For the new web

HTTP APIs are run on top of HTTP, the original specification, whereas gRPC is designed for HTTP/2, a significant revision to the original HTTP protocol. HTTP/2 is more reliable and faster than HTTP/1 and also supports additional features, including but not limited to bi-directional streaming. HTTP served the world better, but it is time we adopt the future.

Efficiency

gRPC uses Protobuf, a binary machine-readable message format. Serialising of payloads in both client/server is faster and results in smaller payloads making it suitable for bandwidth-constrained scenarios.

Strict specification

gRPC implements a strict specification, unlike HTTP APIs. HTTP APIs specifications are fragmented as developers constantly debate response codes, HTTP verbs and URL formats. A strict specification makes developers follow a similar design across languages and platforms. This requirement reduces fragmentation and, as a result, saves time.

Streaming

Unlike HTTP, HTTP/2 provides a foundation for long-lived, real-time communication streams, and GRPC supports all types of streaming:

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

Handling timeouts

gRPC clients can specify the time they are willing to wait for a response. Once this specified timeout is exceeded, the server can decide how to proceed. For example, the server may choose to terminate a DB query or other process taking time.

Language Support

gRPC supports various languages, or at least it has example implementations for these languages in the GRPC library.

• C#
• C++
• Dart
• Go
• Java
• Kotlin
• Node
• Objective-C
• PHP
• Python
• Ruby
• Web JS

Note: Browsers lack support for the original gRPC. Web JS project by gRPC brings browser support for browser clients.

Disadvantages

• Limited browser support (gRPC Web)
• Protobuf is binary and is not human-readable - requires additional tools

gRPC use cases

Now that you are aware of the advantages and disadvantages of gRPC, it is time to discuss when and where gRPC fits the best.

• Microservices that can benefit from high throughput, low latency communication
• Realtime communication that can benefit from bi-directional streaming
• Projects that utilise more than one language
• Low bandwidth networks
• Inner-process communication (IPC)

Conclusion

Many modern-day applications require communication with in-house built services or third-party services through API calls. gRPC provides us with a modern, efficient and fast way of communicating with such services. gRPC is my favourite way of interfacing multiple services and is the preferred choice of many developers worldwide.

If you are interested in any technical consult on the matter, I am happy to answer your queries.