gRPC Protocol

Jump to navigation Jump to search

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).



  • 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.


    • 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. ...



    • 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.


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.



    • 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.