Stephanie Gredell

The slow crawl through GRPC: Up and Running continues. You can purchase it here.

I honestly haven’t made a ton of progress because I’ve read and re-read the same few pages while doing the coding examples. However, I did get through most of chapter 2 which gives a very preliminary introduction to using Protobuf and gRPC. I have one more thing to do to finish it off which is running building and running the app (all done through the coding examples that they give, none done from my own creativity).

One of the things that has thrown me for a loop while reading this is the order that they present information. They went into some Java stuff to build out the client and then they went into setting up Gradle. As a person that barely knows Gradle (like just enough to get by on my day to day work), it would have been more helpful if they presented setting up the Gradle project before showing the code examples. Perhaps it’s just me.

So, what have I learned? A lot. Here are some GRPC specific things. There was a ton that I thought was pretty “common sense” and carried over from my general programming knowledge that I didn’t note here.

• Service definitions is one of the first things you do and that is set up in the proto files. Once you define the definition and compile the proto files, it generates an interface where then you can define the implementation of each method.
• A service is a collection of methods that are exposed (and can be executed by the client).
• Alongside service definitions, you can also define message types. A message is the data structure that is exchanged between client and service. A message type contains fields (similar to an object) and each field is numbered so that the field can be uniquely identified.
• We can only have 1 input parameter per method and can only return one value (I knew this already but worth knowing that the same holds true in the GRPC world). If we need to pass multiple values, we need to define a message type and group all the values.
• You can import from another proto file if you need to use message types defined elsewhere.
• You can manually compile the proto file(s) using the protocol buffer compiler or leverage something like Gradle that has a Protobuf plugin that can do it when you run the build step.

This is as far as I’ve really digested. I’ll cover the rest of chapter 2 once I’ve really digested it and executed the code. However, I’ve been trying to move slower through this book so I can really absorb what it has to offer.

The side challenge of all this is deciding on the the tools I want to invest in. At my job, the tools to use are given. There are certain tools supported by the company that will facilitate getting the job done. However, for my own personal stuff, I always struggle between going to what is familiar vs something different. Going with the familiar means purchasing the same tools that I use at work. That works fine but if the whole point is to learn new things, that’s not fulfilling the mission. Going with something completely different means that I’m expanding my horizons and pushing my comfort zone out more.

I started reading gRPC Up and Running. Purchase it here.

I’ve finished the first two chapters of this book and my first impression is that it started out slow but quickly picked up pace and jumped right into the details. I still have a long ways to go before finishing the book but so far, I think I like it. I’ve dissected a small part of the first chapter and compiled some of my notes.

The g in “gRPC” stands for something different in every release. I didn’t know this. I just assumed that it stood for Google. Very clever.

The general process for developing a gRPC application is as follows:

• Develop a service interface in a proto file
• Generate server side code (server skeleton)
• Generate client side code (client stub)

The client can invoke methods in your service interface. gRPC framework deals with all the complexities that includes handling strict service contracts, serialization of data, network communications, authentication, access control, observability, etc.

gRPC uses protocol buffers as the IDL (Protobuf). Protocol buffers are language agnostic and platform neutral. It is the mechanism used for serializing structured data.

gRPC is the child of many iterations of protocols that came before it. Some of those predecessors include:

• Conventional RPC
• SOAP
• REST

It also discusses the downsides of REST.

• Inefficient text-based message protocol
• Lacks strongly typed interfaces between apps
• Hard to enforce

More to come later but this is as much as I’ve gotten so far. I plan on writing and running their code examples for some hands on experience.