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.

I’m in the middle of reading Seven Languages in Seven Weeks. Purchase it here.

“The question isn’t ‘What are we going to do?’ The question is ‘What are we not going to do?’”
— Ferris Bueller

In an ever changing world where companies try to be innovative and progress in their business, the culture will certainly change as evolution happens. If you remain at a company for a significant length of time, you’ve probably seen this happen.

In my experience, these are some lessons I’ve learned:

• Things will change. Process will change. Values will change. Priorities will change. People will change. Work will change. Change is the only constant.
• If you are unable to adapt to change, you will likely not survive.
• Flexibility is king.

As we adapt to new environments, processes, people or values, the quote strikes me as “I will do what needs to be done for the success of my team” but I’ve never asked myself “Is there anything I wouldn’t do for the success of my team?”

Or better yet, will there be anything my team won’t do for the success of the company? Or is there a process my team wouldn’t change because as a group, we feel strongly about it?

Do managers ship code? Do they ramp new features? Do they tell the oncall engineer when to deploy? Sure, in some companies, they do. In some companies, they don’t. In places where this does happen, the managers should be aware of all the things going on and hopefully, they know the risks involved when they make their decisions. However there is the other perspective where they are supposed to be people managers and it can be seen as overstepping boundaries. I don’t think managers being hands on is bad nor do I think it’s bad if they’re hands off and trust in their team to do the work and make the correct decision. I think the perception of either side depends on the understanding of boundaries and knowing what to expect.

It can be the same sort of thing when it comes to engineers. We all have our limits but we strongly consider the things we will do or ideals we will hold. We automatically assume that if we define the things we will do, it implies the things we won’t do. But is that really the case?

I think teams often have unspoken boundaries and I didn’t realize until recently how problematic that is. Because they’re unspoken, they’re often assumed and when the moment comes where those boundaries are crossed because of a lack of understanding, there is conflict. When there is conflict, we talk about the things we will do to fix it. But what about the things we won’t do?

It’s often easier to answer the question “what will we do” because the answer is a much smaller list of possibilities than “what will we not do” but I think considering at least both sides for even a small moment could add a lot of clarity going forward. I think if there were more clarity around the things we won’t do, less conflict will come up and the things that we will do will become easier to navigate around.