Warning! The code (ASM) part of this article is not fully correct and doesn't scale to more layers of the tree. While I solved this problem offline, I did not update this article. Once I do, this warning will be off.

Looking into optimizing one of my APIs, I recently stumbled upon the following resource: Common design patterns. This contains a lot of insights on how to design proto files in order to make gRPC APIs more idiomatic or more efficient. Within this document, I found the pagination part interesting and decided to write an article on how to implement it.

Recently, I've been looking for a good alternative to Traefik as Reverse Proxy for gRPC services. Traefik has great support for gRPC and other common features, but Envoy comes with Protobuf-backed configuration and even greater support for gRPC services. In the article, I want to show how you can make Envoy use your custom authorization logic before redirecting (or not) the request to other services.

Recently, I've been working on adding support for SourceCodeInfo into Protein. This required checking a lot of Column/Line ranges in string. An example of this is the following. Given a oneof like this:

Recently I had to design authentication for a Blazor Application. After finishing implementing, I soon faced the need to know which RPC endpoint needs authentication and which doesn't. And while part of the problem is a solved one, I still needed a mechanism to let me define this. Let's see how.

Did you ever need to know, inside your program, on which go version you are running? That's what we are going to solve today. The most common use case for this is logging. We want to be able to debug by reproducing the environment of where the binary is running as close as possible. This starts by knowing which version of go we are using.

Recently I've discovered two interesting was in creating monorepos for go projects. In this article we are going to talk about the advantages and disadvantages of each of these techniques.

In this article we are going to finally get to building the Parser. We are going to start parsing syntax, package and import statements, and we are going to see how to represent our serializable AST. Hope you are ready for this, it's gonna be fun!

This article is a small one intended to solve a bug related to token position. As of right now, we only tested that our token got the right literal and the right token kind. In this article, we are going to add the position checking in our tests.

In this article we are going to delve into the second part of the lexing which is tokenizing more advanced part of the input. More precisely, we are going to lex spaces (whitespaces, new lines, ...), comments, Identifiers, Numbers (Int and Float), and Strings. At the end of this article, we will have a fully functioning lexer that can tokenize the descriptor.proto which is the longest proto file in the protobuf repo. Let's get started.

As promised in a LinkedIn Poll, we are going to develop Parser for proto files which will create an AST that is serializable in Protobuf itself. Obviously, this is going to be a series of articles because we need to write quite a lot of parsing code. However, I believe that this is worth doing since we are going to see another use of Protobuf outside of gRPC.

Recently, I answered a StackOverflow question related to writing protoc plugins and Protobuf custom options. I thought this would be interesting to share how to write one because I believe this is quite an involved process and it fits the context of an article.

Recently, I've been working with Markus Tacker on improving his comparison of JSON vs. Protobuf for a Wifi Site Survey. This has been a lot of fun and I thought I could do a simple post about what went well and what my mistakes were.

As this is a common and not well documented mistake that developers are doing, I decided to do a post explaining the problem that you might face when using repeated fields in your Protobuf messages.

One of the common thing that my students are asking about recently is the difference between 2 Type Embeddings when your are defining a Server type for Service Registration. While this is an important topic, the gRPC doc seems to only mention that the Unimplemented version is for Forward Compatibility, and my course, up until now, uses the name of the generated Service Server directly. As such, I thought I would give an explanation on why I now recommend to use Unimplemented and some examples of the 3 Type Embeddings that you can use.

This article is much more a note to myself than something else but this might be interesting for people out there. I wanted to calculate the thresholds at which it is better it is to use a fixed rather than a varint.

While working on a new course, I was looking for an example to store a Color in Protocol Buffers. At first this seemed like an easy task but it turned out to be an interesting example of optimization. Let's work through it.

For student taking my class on gRPC C# (Udemy), here is the way to get the code.

Caching is everywhere! It is an essential part of most applications out there and so obviously there are a lot of options you can chose from. Here is a non exhaustive list:

After the decision of using Crashlytics for our first pilot (Education for ethopia), the tech team discovered that one particular crash was redundant. This crash was due to a malformed Intent between the video player in portrait mode and the video player in landscape mode.

After being used to the traditional way of debug an android app by using mocking and interceptors, I came across an interesting problem with gRPC. I wanted to do the same. Basically, add an interceptor that mock a server response.

Recently, I was trying to handle errors in the programming language I'm developping. Nothing fancy here and the problem was quickly solved with a simple: