Page 52 - MSDN Magazine, September 2019
P. 52

Cutting EdgE
Streaming Methods in ASP.NET Core gRPC Services
DINO ESPOSITO
In the previous installment of Cutting Edge, I walked through building a new type of service based on the gRPC framework that (although available to C# developers for a while) in ASP.NET Core 3.0 debuts as a native service hosted directly by Kestrel. The gRPC framework is suited for peer-to-peer binary communication between connected endpoints—mostly, but not necessarily, microservices. It also supports up-to-date technical solutions such as Google Proto- buf for serialization of content and HTTP/2 for transportation.
Visual Studio 2019 comes with an ASP.NET Core 3.0 project template for creating the skeleton of a gRPC service in just a few clicks. For a primer both about gRPC and the starter kit generated by Visual Studio, you can check out my July column at msdn.com/ magazine/mt833481. This month I take my exploration of gRPC one step further. First, I’ll cover the underlying tooling in a bit more detail. In fact, some tooling is necessary to parse the content of the .proto file to C# classes to be used as the foundation of both client and service implementations. In addition, I’ll touch on stream- ing methods and complex message classes. Finally, I’ll focus on how to integrate streamed gRPC methods in the UI of a Web client application.
Building the gRPC Service
The built-in Visual Studio project template places the service inter- face definition file (the .proto file) in a subfolder named protos located in the same service project. In this article, though, I’ll take a different approach and start by adding a brand new .NET Standard 2.0 class library to the initially empty solution.
The proto class library doesn’t explicitly contain any C# class. Allitcontainsisoneormore.protofiles.Youcanorganize.proto files in folders and subfolders at your leisure. In the sample appli- cation, I have a single .proto file for a sample service located under the protos project folder. Here’s an excerpt from the service block
of the sample .proto file:
service H2H {
rpc Details (H2HRequest) returns (H2HReply) {}
}
The H2H sample service is expected to retrieve some sport-related information from some remote location. The Details method passes a head-to-head request and receives the score of the past matches between specified players or teams. Here’s what the H2HRequest and H2HReply messages may look like:
message H2HRequest { string Team1 = 1; string Team2 = 2;
}
message H2HReply {
uint32 Won1 = 1; uint32 Won2 = 2; bool Success = 3;
}
The first message type passes information about the teams to process, whereas the latter receives the history of past matches and a Boolean flag that denotes success or failure of the operation. So far so good. Everything in the messages is defined as we’ve seen in the previous article. Using the gRPC jargon, the Details method is a unary method, meaning that every request receives one (and only one) response. This is the most common way of coding a gRPC service, however. Let’s add streaming capabilities, like so:
rpc MultiDetails (H2HMultiRequest) returns (stream H2HMultiReply) {}
You can organize .proto files in folders and subfolders at your leisure.
The new MultiDetails method is a server-side streaming method, meaning that for each request it gets from some gRPC client it may return multiple responses. In this example, the client might send an array of head-to-head requests and receive individual head-to- head responses in an asynchronous way as they’re elaborated on the serviceend.Forthistohappen,thegRPCservicemethodmustbe labeled with the stream keyword in the returns section. A stream method may require ad hoc message types, too, as shown here:
message H2HMultiRequest {
string Team = 1;
repeated string OpponentTeam = 2;
}
As mentioned, the client may ask for a head-to-head record between one particular team and an array of other teams. The repeated keyword in the message type just denotes that the OpponentTeam member may appear more than once. In pure C# terms, the H2HMultiRequest message type is conceptually equiv- alent to the following pseudocode:
class H2HMultiRequest {
string Team {get; set;}
IEnumerable<string> OpponentTeam {get; set;} }
Code download available at msdn.com/magazine/0919magcode.
44 msdn magazine


































































































   50   51   52   53   54