{"id":87072,"date":"2020-04-29T19:56:44","date_gmt":"2020-04-29T19:56:44","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=87072"},"modified":"2022-05-02T20:39:24","modified_gmt":"2022-05-02T20:39:24","slug":"integrating-asp-net-core-with-grpc","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/integrating-asp-net-core-with-grpc\/","title":{"rendered":"Integrating ASP.NET Core with gRPC"},"content":{"rendered":"

Have you ever dealt with RPC<\/strong><\/a>? It stands for Remote Procedure Call<\/em>, a famous term from distributed computing for when you need to call a service routine from one machine to another . It\u2019s like the basics for anyone who wishes to create REST\/SOAP requests or GraphQL architectures. You need to understand a bunch of concepts like parallelism, clusters, network latency, failover and fallbacks, just to get started. This article discusses integrating ASP.NET Core with gRPC.<\/p>\n

Although it\u2019s an interesting topic to discuss, that\u2019s not the focus here. I\u2019ll talk about gRPC<\/a>, the official Google\u2019s modernization of the protocol into a powerful framework. It is modern, open source and can run in any type of environment. It adds inherent load balancing, tracing, health checking and authentication (this one, by the way, is required right at the beginning).<\/p>\n

Before you start thinking that Google wants to \u201cremake\u201d the web, since you already have HTTP and web services to provide such features, gRPC goes a bit beyond. It\u2019s based in HTTP\/2 which, automatically, says it\u2019s much faster. Besides that, Google redesigned it in a way speed is at the top of the priority list.<\/p>\n

In always-needy architectures like those huge companies (like Netflix, Cisco and Google itself) have, efficiency is a must. Microservices and distributed systems may communicate with each other through protocols and channels that should be fast.<\/p>\n

Think about it: if you choose RESTful, there\u2019s a couple of design patterns and rules you need to obey. In turn, you\u2019re going to be working under HTTP (verbose) and making hundreds of calls because your code design can\u2019t be messed up by ugly endpoints. While there are already have options like GraphQL, for example, does it really need to communicate with HTTP-only?<\/p>\n

If your client and server applications are made by you (or your company), and there\u2019s no need to expose it out there (still, options would be available through public Web Services, API Gateway, etc.), why not?<\/p>\n

It\u2019s faster, available to 10 programming languages (including web, i.e., JavaScript into Docker images), bi-directional (for cases where you need constant data flowing through streams from both sides) and so much more.<\/p>\n

All the magic happens with Protocol Buffers<\/a> and stubs. Of course, protobuf is Google\u2019s as well. It\u2019s their language\/platform-neutral mechanism for data serialization and deserialization. The good news is that you\u2019re not stuck into the proto universe, gRPC is encoding agnostic too<\/a>, which means that JSON, XML, etc. can also be used to serialize the data if you prefer so.<\/p>\n

Like everything else, there are pros and cons. While it is good to have the familiar JSON syntax, protobuf allows validations, data types, service creation. On the other hand, it is not human readable, hard to decode and takes more time to process compared to JSON.<\/p>\n

This is how a gRPC workflow takes place:<\/p>\n

Protobufs > protoc > generated code\/stubs > client\/server<\/p>\n

First, you create your proto files, defining not only the data structure, types and validations but also the services to be implemented by the server app along with the contract to be followed by the client stubs.<\/p>\n

Then, depending on the language and platform you\u2019re using, and after you compile it (protoc<\/em>, the proto compiler), some code is going to be autogenerated, based on those definitions. After that, you can create your server and client code.<\/p>\n

It\u2019s time to stop talking now and move to action. For this article, I\u2019ll demonstrate how to create a gRPC server based in a proto contract, as well as two clients: one for a Console App and another for a fully-functional web application (made with ASP.NET Web MVC), for you to check how this type of integration works for the two worlds.<\/p>\n

Setup<\/h2>\n

Please, make sure you have the latest version of Visual Studio (Community Edition). When installing it, check the ASP.NET and web development<\/em> workload. If you already have VS installed, but not this workload, please refer to this link<\/a>. Finally, .NET Core 3.0 SDK<\/a> (or later) is also needed.<\/p>\n

There\u2019s no need to install anything related to gRPC. Visual Studio already has presets for it, and the rest are NuGet dependencies.<\/p>\n

Open Visual Studio and go to \u201cCreate a new project<\/em>\u201d option. (The completed project can be found here<\/a>.)Then, search for the \u201cgrpc<\/em>\u201d term and select the option like below:<\/p>\n

\"Tela<\/p>\n

Figure 1. Creating a new gRPC service project<\/strong><\/p>\n

Click Next<\/em>. Then, type the name of the project like in Figure 2, select the directory of preference and click Create<\/em>.<\/p>\n

\"Tela<\/p>\n

Figure 2. Giving the project a name<\/strong><\/p>\n

For the next screen, select the only available option \u201cgRPC Service\u201d and, finally, click the Create<\/em> button.<\/p>\n

Take a look at the generated files:<\/p>\n