Do you remember when applications ran on a single machine and didn’t have to talk to each other or to other machines? All was well with the world…or was it? Those were simpler times, applications didn’t need to interact with outside entities but then the walls started to come down. Applications realized they were lonely and needed data/content/external interactions to be whole. The problem was how can applications communicate with the outside world. Along came a plethora of communications technologies to try and solve this conundrum. Things like remoting, WCF, REST, WebAPI and many many more came to be. All these technologies have their pros and cons. Some work better in one instance and others work better in different instances. Finding the right one is the consummate challenge.
I am working on a project where we are going through an exercise to modernize a complex system. The system consists of a number of services that need to communicate with each other and with the front end. The application is written in .Net for the most part. One of the goals is to move away from the .Net Framework so that we can containerize the services and host them in Docker. That means a move to .Net Core (Core 3 most likely). As everyone knows .Net Core does not play nicely with WCF (the current communication technology). Obviously that has to go. We could go with technologies like REST or build out a WebAPI and who knows in the end we may go with one of those. But since it is early in the process we decided to investigate gRCP. I have heard of it but haven’t really used so I decided to get my hand on it and see if it can work for us.
What is gRPC
The first question you have to ask is "what is gRPC"? It is an open source remote procedure call (RPC) system initially developed internally by Google. According to the about page, 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 back end services." It uses Protocol Buffers as the interface description language.
Google had been using a RPC system, called Stubby, for over a decade and is what has been powering Google’s microservice architecture. In 2015, they wanted to upgrade Stubby and decided to do it in the open. Hence gRPC is born. You can see the code for yourself at their GitHub page and maybe even contribute. The fact that it has been around for over a decade and is powering Google’s back end makes pretty enticing. Also the ability to connect services and clients, written in different languages is pretty cool too!
Protocol Buffers
Above I mention that gRPC uses Protocol Buffers as the interface description language…What does that mean? Protocol Buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data which WAS also developed by Google. They designed it to be smaller, faster, and simple that XML. You define a your implementation in a .proto file and the compile it into your language of choice. There are compilers available in many of the popular languages. For instance in C# your proto file gets compiled into C# class that can be used in your code.
Summary
There are some pretty big names, beside Google using it like, Square and NETFLIX. I can’t wait to start playing with gRPC. I will start by doing the "Hello World" examples and then move onto what I like to call the "File New" test. There is still a lot to learn but my initial impression is that it could a contender for my current project
Dave's Two Cents 