The gRPC is one of the Remote Procedure Call (RPC), It was developed by Google. They needed a messaging protocol that can respond on the distributed computing environment in real-time when users operate the Data plane of the Google Cloud. And it was leveraged for maintaining of the Control plane of Google Cloud also, to keep high quality cloud services.
The gRPC uses the Stubby they created: a framework of one of the RPC. Then the gRPC become to open source, and it has be the incubating project of CNCF since 2017.
Microsoft supports many development environments for an application using the gRPC-Web and the gRPC-over-HTTP/2 (see Microsoft official document ‘gRPC on .NET supported platforms‘).
This article describe mechanism of .NET application using the gRPC architecture and an application that uses the gRPC works as the Message Oriented Middleware.
The article ‘ASP.NET Core gRPC & gRPCurl tool‘ describes how to implement gRPC application service from Azure App Service.
• gRPC-dotnet
The gRPC-dotnet is implementation of .NET that is to use the gRPC Core Stack. It’s structed with namespaces of Grpc.AspNetCore and Grpc.AspNetCore.Server.Reflection. For creation of these stub, namespaces Grpc.Net.Client, Grpc.Tools, and Google.Protobuf architecture are used.
The Grpc.AspNetCore namespace is the gRPC service itself, and the Grpc.AspNetCore.Server.Reflection namespace works for providing a description of the gRPC service to client apps just like the Swagger.
On the other hand, the Grpc.Tools namespace is auto generate a stub of client side that uses the Protobuf of the gRPC. The Grpc.Tools namespace generates a stub with the Google.Protobuf architecture, The Google.Protobuf called from the Grpc.Tools namespace is pure C# implementation that does not use native component of the gRPC core stack.
There was no HTTP/2 library of C# until gRPC-dotnet is developed, so gRPC apps of C# were developed with gRPC.Core that includes HTTP/2 library. The gRPC.Core namespace moved to the state of the Maintenance Only at May 2021, then at May 2022, it was in the state of the Deprecated (Please refer to the great article ‘The future of gRPC in C# belongs to grpc-dotnet‘).
• The gRPC is a protocol for the Message Oriented Middleware.
The gRPC extends the Remote Procedure Call (RPC). The official website says, ‘A high performance, open-source universal RPC framework’.
The first description is an aspect of universal RPC framework, it can be used in multiple languages and can enforce service contracts on multiple first- and third-party services using HTTP/2. It means that the gRPC can generate clients and servers in multiple languages, generated code is able to run on each language environment (C++, Java, Go, Node, Ruby, Python and C# across Linux, Windows and Mac). The gRPC as a framework is universal because it supports also development on many environment. For instance, mobile apps development of iOS and Android is supported with Objective-C and Android Java libraries, it can execute single-line installation in most languages.
The RPC calls any functions on destination that are an object, in other words, service contracts have to describe the objects, so gRPC use the Protocol Buffers for run on universal environment. The Protocol Buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data (quote from the official website). It can describe objects of services side and edge side both.
The second description is an aspect of high performance of the gRPC, availability of object description affects streaming or unary flow control from each side of service and edge. In the case of using the forward error correction (FEC) mechanism for error handling, it is better that an object error is supported at communication level same as a connection error instead of at an application level. An access control of authentication & authorization typically uses JSON as a container of a security token, object description of the Protocol Buffers is useful for transfer of a security token too, also useful for serialization/deserialization. The RPC extends of the gRPC are also useful at other aspects such as distributed tracing, binding as synchronization/asynchronization, response of cancel/timeout, health checking, load balancing, logging and monitoring and tracing etc..
The gRPC was developed for distributed computing. Distributed computing has the Message-Oriented Middleware, the Distributed Directory, the Service Discovery, the Stateful Middle Tier, the Stateless Actor Activator and so on. There are many types in the Message Oriented Middleware such as the Pub-Sub, the Message Queue, the Fan-out, the Request/Response, the Point to Point, the Remote Procedure Call and so forth. The Remote Procedure Call run on several type protocols like the HTTP, the HTTP/2, the TCP/IP, the Internet InterORB protocol. The gRPC is extends HTTP/2 with the Protocol Buffers. Thus, the gRPC has to be used in correct situation, in other words, what kind of a solution architecture, what part of the system or which direction of procedures call.
The gRPC is like as the WCF or the DCOM that uses the Distributed Object in synchronize communication although, it can communicate asynchronously, and also can bidirectional communication between service and client because it transfer objects with the HTT/2 protocol.
The Distributed Object of unary RPC makes a stub of a service side object on a client side, then a client executes a client-side object. In other hand, the gRPC transfers a description of service side object, then a client side calls service side procedure.
If you familiar with synchronize communication on the DCOM or the WCF architecture, aware consistency of a state of services on the gRPC communication. In the case of a unary RPC, a client-side application uses same object of service side as stub, thus typically the application care about consistency of only service side state although, in contrast a state of client side or service side is not guaranteed on the gRPC communication because the gRPC communication uses remotely individual object of service side or client side and usually communicate with asynchronously. Though the gRPC can communicate as synchronously for waiting remote procedure response like unary RPC, if use the Backend for Frontends pattern for design of cloud native solution, it needs design as distributed computing like Microservices. Please refer to the website of Sam Newman (‘Pattern: Backends For Frontends‘), and Microsoft official document (‘Backends for Frontends pattern: Microsoft learn‘).
No responses yet