gRPC Protocol
A gRPC Protocol is an open-source remote procedure call system that uses HTTP/2 (for transport) and Protocol Buffers (as the interface description language) to enable high-performance distributed system communication.
- AKA: gRPC, Google Remote Procedure Call, gRPC Framework.
- Context:
- It can enable High Performance Communication through HTTP/2 protocol.
- It can support Microservices Design through coarse-grained message exchange.
- It can facilitate Bidirectional Streaming through streaming protocol capabilities.
- It can avoid distributed computing challenges through message-based architecture.
- It can optimize network communication through protocol buffer serialization.
- It can provide Cross Platform Support through language-agnostic design.
- It can deploy Server Implementation through gRPC server and gRPC client libraries.
- ...
- It can (often) implement Authentication Services through built-in security features.
- It can (often) support Load Balancing through pluggable infrastructure.
- It can (often) enable Health Checking through monitoring capabilities.
- It can (often) maintain Distributed Tracing through observability features.
- ...
- It can range from being a Simple RPC Implementation to being a Complex Streaming System, depending on its communication patterns.
- It can range from being a Basic Service Definition to being an Advanced Service Mesh, depending on its deployment complexity.
- ...
- It can integrate with Protocol Buffer Compiler for interface generation.
- It can connect to gRPC Gateway for REST compatibility.
- It can support Service Discovery Systems for dynamic routing.
- ...
- Examples:
- gRPC Implementations, such as:
- gRPC Versions, such as:
- gRPC v1.11.0 (~2018-04-14) with improved performance features.
- gRPC v1.6.0 (~2017-08-30) with core functionalitys.
- ...
- Counter-Examples:
- WebSocket Protocol, which focuses on full-duplex communication rather than RPC paradigm.
- REST Architecture, which uses resource-based approach instead of procedure-based approach.
- SOAP Protocol, which relies on XML messaging rather than protocol buffers.
- ZeroMQ, which provides message queue abstraction instead of RPC framework.
- WCF, which is Microsoft-specific rather than platform-agnostic.
- See: Interface Description Language, Remote Procedure Call, HTTP/2, Protocol Buffers, Apache Thrift, SOAP, Gatlin-gRPC, Microservices Architecture, Service Mesh, Load Balancer.
References
2023
- chat
- HTTP, gRPC, and WebSockets are all network protocols used for communication between computer systems, but they have different characteristics and use cases. Here is a brief overview of each protocol:
- HTTP (Hypertext Transfer Protocol): HTTP is a request-response protocol used for transmitting data over the internet. It is the foundation of the World Wide Web and is used for transmitting data between web servers and web browsers. HTTP is a stateless protocol, which means that each request/response cycle is independent of the others, and it uses TCP (Transmission Control Protocol) as its transport layer protocol.
- gRPC: gRPC is a modern open-source framework developed by Google for building high-performance, language-agnostic microservices. It is based on the Remote Procedure Call (RPC) paradigm, which allows applications to call functions or procedures on remote servers as if they were local functions. gRPC uses the Protocol Buffers data format and supports multiple transport protocols, including HTTP/2, allowing for fast and efficient communication between systems.
- WebSockets: WebSockets is a protocol that provides full-duplex communication channels over a single TCP connection. It is used for real-time communication between web browsers and web servers, allowing for interactive applications such as online games or chat systems. WebSockets allow for bi-directional communication, which means that data can be sent and received in both directions simultaneously, making it a more efficient way to handle real-time data.
- Overall, each of these protocols has its own strengths and weaknesses and is suited for different types of applications. HTTP is used for traditional client-server web applications, while gRPC is used for high-performance microservices, and WebSockets is used for real-time communication. Understanding the differences between these protocols can help developers choose the best option for their specific use case.
- HTTP, gRPC, and WebSockets are all network protocols used for communication between computer systems, but they have different characteristics and use cases. Here is a brief overview of each protocol:
2020
- https://grpc.io/
- QUOTE: ... gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services. ...
2019
- https://grpc.io/docs/guides/concepts/
- QUOTE: ... Like many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. By default, gRPC uses protocol buffers as the Interface Definition Language (IDL) for describing both the service interface and the structure of the payload messages. It is possible to use other alternatives if desired. ...
2018a
- https://grpc.io/faq/
- QUOTE:
- What is gRPC? gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. It enables client and server applications to communicate transparently, and makes it easier to build connected systems.
- …
- Why is gRPC better/worse than REST?
gRPC largely follows HTTP semantics over HTTP/2 but we explicitly allow for full-duplex streaming. We diverge from typical REST conventions as we use static paths for performance reasons during call dispatch as parsing call parameters from paths, query parameters and payload body adds latency and complexity. We have also formalized a set of errors that we believe are more directly applicable to API use cases than the HTTP status codes.
- …
- QUOTE:
2018b
Package Description io.grpc The gRPC core public API. io.grpc.auth Implementations of CallCredentials and authentication related API. io.grpc.inprocess The in-process transport which is for when a server is in the same process as the client. io.grpc.netty The main transport implementation based on Netty, for both the client and the server. io.grpc.okhttp A lightweight transport based on OkHttp, mainly for use on Android (client-only). io.grpc.protobuf API for gRPC over Protocol Buffers, including tools for serializing and de-serializing protobuf messages. io.grpc.protobuf.lite API for gRPC over Protocol Buffers with proto message classes generated by the Lite Runtime library. io.grpc.protobuf.nano API for gRPC over Protocol Buffers with proto message classes generated by the JavaNano compiler. io.grpc.stub API for the Stub layer. io.grpc.testing API that is useful for testing gRPC. io.grpc.util Utilities with advanced features in the core layer that user can optionally use.
2017
- (Wikipedia, 2017) ⇒ https://en.wikipedia.org/wiki/gRPC Retrieved:2017-6-19.
- gRPC is an open source remote procedure call (RPC) system initially developed at Google. 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.
2015
- https://grpc.io/blog/principles
- QUOTE: oogle has been using a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across our data centers for over a decade. Our internal systems have long embraced the microservice architecture gaining popularity today. Having a uniform, cross-platform RPC infrastructure has allowed for the rollout of fleet-wide improvements in efficiency, security, reliability and behavioral analysis critical to supporting the incredible growth seen in that period.
Stubby has many great features - however, it's not based on any standard and is too tightly coupled to our internal infrastructure to be considered suitable for public release. With the advent of SPDY, HTTP/2, and QUIC, many of these same features have appeared in public standards, together with other features that Stubby does not provide. It became clear that it was time to rework Stubby to take advantage of this standardization, and to extend its applicability to mobile, IoT, and Cloud use-cases.
- Services not Objects, Messages not References - Promote the microservices design philosophy of coarse-grained message exchange between systems while avoiding the pitfalls of distributed objects and the fallacies of ignoring the network.
- Coverage & Simplicity - The stack should be available on every popular development platform and easy for someone to build for their platform of choice. It should be viable on CPU & memory limited devices.
- QUOTE: oogle has been using a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across our data centers for over a decade. Our internal systems have long embraced the microservice architecture gaining popularity today. Having a uniform, cross-platform RPC infrastructure has allowed for the rollout of fleet-wide improvements in efficiency, security, reliability and behavioral analysis critical to supporting the incredible growth seen in that period.