gRPC (gRPC Remote Procedure Calls) is a cross-platform open source high performance remote procedure call (RPC) framework. gRPC was initially created by Google, which used a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across its data centers from about 2001. In March 2015, Google decided to build the next version of Stubby and make it open source. The result was gRPC, which is now used in many organizations aside from Google to power use cases from microservices to the "last mile" of computing (mobile, web, and Internet of Things).
It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts. It generates cross-platform client and server bindings for many languages. Most common usage scenarios include connecting services in a microservices style architecture, or connecting mobile device clients to backend services.gRPC's complex use of HTTP/2 makes it impossible to implement a gRPC client in the browser, instead of requiring a proxy.
gRPC, which stands for Google Remote Procedure Call, is an open-source framework developed by Google that enables communication between client and server applications using a simple, high-performance, language-agnostic model[8].
It uses HTTP/2 for transport and Protocol Buffers (protobufs) as its Interface Definition Language (IDL), which allows for efficient binary serialization, smaller message sizes, and faster parsing[1][2][3].
The Problem with Client Libraries
• Any communication protocol needs client library for the language of choice
• SOAP Library
• HTTP Client Library
• Hard-to maintain and patch client libraries
• HTTP/1.1, HTTP/2, new features, security etc.
gRPC modes
• Unary RPC -> Simple Request Response
• Server streaming RPC -> Client requests and server streams a large file
• Client streaming RPC -> Client pulls a large file from Server
• Bidirectional streaming PC -> WebRTC, both Client and Server talk to each other
Pros of gRPC
- Performance: gRPC uses HTTP/2 and binary serialization, which results in improved performance and reduced latency. It is significantly faster than REST+JSON communication[3:1][1:1].
- Language Support: gRPC supports a wide range of programming languages, including Java, C++, Python, C#, Dart, Go, Kotlin, Node.js, Objective-C, PHP, Ruby, and Swift[4].
- Streaming: gRPC offers server, client, and bidirectional streaming modes for real-time communication[1:2].
- Strongly Typed: gRPC is strongly typed, which can help prevent errors[5].
- Built-in Code Generation: gRPC has automated code generation in different programming languages, which can simplify development[3:2].
- Multiplexing: gRPC supports multiplexing, which can reduce network delay[4:1].
- Cancel Request: Canceling an existing request possible.
Cons of gRPC
- Complexity: gRPC can be more complex compared to REST APIs, which may introduce overhead in certain use cases[1:3]. Schema adds complexities.
- Lack of Maturity: Compared to other technologies like GraphQL, gRPC is less mature with fewer resources available for developers[3:3].
- Browser Support: gRPC may not be fully supported in older browsers[1:4].
- Learning Curve: gRPC requires familiarity with Protocol Buffers and HTTP/2, which can be a learning curve for some developers[1:5].
- Error handling
- No native browser support
- Timeouts (pub/sub)
Compared to other network protocols, gRPC is particularly well-suited for high-performance, large-scale distributed applications, especially those involving real-time communication and cross-platform interoperability. However, its complexity and learning curve may make it less suitable for smaller projects or teams without the necessary expertise[5:1][1:6].
