gRPC is an open-source remote procedure call (RPC) framework for building microservices. This framework supports both an asynchronous and synchronous communication model to allow developers to create services and connected systems. It also supports features such as multiplexing, full-duplex, and request/response network protocols that would enable you to exchange messages across services running internally. In a gRPC system, there are four (4) different kinds of RPC methods that let you define a service. They include:
A Unary/Simple RPC: this service method works just like a regular function call. It supports a typical Request/Response model where the client sends out a single request to the RPC server using the stub and waits to get a single response back.
A Server-side streaming RPC: this is where the client sends out a request to the server and waits to get a stream to read a sequence of messages in return until there are no more messages. gRPC ensures ordering of returned messages within an individual RPC call.
A Client-side streaming RPC: this is where the client writes and sends a sequence of messages to the server via a provided stream and waits to get a response back. Again, gRPC ensures message ordering.
A Bidirectional streaming RPC: this service method supports a read-write stream that the two sides (both client and server) can use to send a sequence of messages. The two streams function independently, allowing clients and servers to read and write in any order of their choice. gRPC preserves message ordering in each stream.
Google developed and released the initial version of gRPC (v1.0) in August 2016. Within the first year of its release, gRPC was adopted by startups, enterprise companies, and open-source projects worldwide. All gRPC's implementations are licensed under Apache License 2.0. It supports programming languages such as Android Java, C#, C++, Dart, Go, Java, Kotlin/JVM, Node.js, Objective-C, PHP, Python, and Ruby. Click here to see all the officially supported gRPC programming language, platform, and OS versions. The gRPC latest release tag is v1.33.2. Today, gRPC is used by Netflix, Square, CockroachDB, Cisco, Juniper Networks, and CoreOS, among others.
The way the gRPC system works depends on the type of RPC method specified for a service. Since gRPC allows you to define four types of service methods, it'll be best to consider them independently to understand their RPC life cycle.
This is the simplest RPC method where the client sends a single request and waits to get back a single response. Here, the gRPC works in the following pattern:
1. Once the client calls a stub method, the server receives a notification that the RPC has been invoked with the client's metadata (information associated with the call to the server and vice versa) and the method name. The client can also specify a deadline or timeout for an RPC before it's terminated.
2. The server can then either return its own initial metadata straight away or wait to receive a client's request message. Unary RPC processing is application-specific.
3. Once the server gets the client's request message, it creates and populates a response doing whatever work is necessary to fulfil the client’s request. If the work is successful, the response is sent back to the client with the status detail (including status code and optional status message) and optional trailing metadata.
4. If the response status is OK, the client receives the response, which completes the call on the client's side.
This RPC lifecycle is similar to a Unary RPC. However, instead of the server returning a single response as with the Unary RPC, it returns a stream of messages in response to a client's request. Once the server gets the client's request message, it sends all its messages along with its status details (status code and optional status message) and optional trailing metadata to the client. The client completes the call once it has received all the server's messages.
This is also similar to a Unary RPC. However, instead of the client sending a single message to the server, it sends a stream of messages. Once the server gets the client's request message, it responds with a single message together with its status details (status code and optional status message) and optional trailing metadata. The server typically responds after it has received all the client's messages.
In a bidirectional streaming RPC, the client initiates the call by invoking the RPC method, and then the server receives the client metadata, method name, and deadline (if applicable). The server can either choose to return its own initial metadata straight away or wait for the client to start streaming messages. The process of bidirectional streaming is application-specific. Here, a server can wait until it has received all of a client's messages before writing its own messages, or the server sends back a response (after getting a request message), then the client sends another request based on the response received, and so on. The latter stream processing is like the server and client playing "ping-pong."
gRPC uses protocol buffers (Protobuf) by default as both the Interface Description Language (IDL) and underlying message interchange format. The protocol buffers enable developers to encode structured data. Protocol buffers also let you describe the service interface (service endpoints) and serializing structured payload messages.
gRPC is designed to use HTTP/2 (a binary protocol) as a transport. This transfer-based protocol supports multiplexing and the traditional Request/Response model. The protocol also enables developers to stream content or information constantly through various options such as server streaming, client streaming, or bidirectional streaming.
gRPC supports multiple authentication mechanisms such as SSL/TLS, ALTS, and token-based authentication with Google. SSL/TLS helps encrypt all the data or messages exchanged between the client and the server. gRPC uses ALTS as a transport security mechanism to protect data in transit. gRPC offers token-based authentication (typically an OAuth2 token) for specific auth flows while accessing Google APIs through gRPC.
gRPC integrates with popular tools such as Traefik, Ambassador, Continuous Delivery Service, Cilium, and BloomRPC, among others.
High-quality HTTP implementations in every language
Supports Protobuf messages
Built on HTTP/2 transfer protocol
Supports various streaming options such as server-, client-, and bidirectional streaming
Uses request-response model
Support for internal services
FeathersJS Deep Dive
An examination of the FeathersJS framework and its realtime functionality — what it is, setup, limitations.
Django Channels are task queues that help with the handling of asynchronous work within the Django framework (which doesn't support asynchronous work).
SignalR is an open-source ASP.NET library that enables servers to send async messages to client-side web applications.