Code review guidelines for GRPC

This blog we are going to discuss some nuances one should be aware of while reviewing GRPC related code. GRPC stands for (gRPC Remote Procedure Call. This is primarily getting developed by google as a platform for binary serialized messaging protocol. gRPC has made api development seamless because of its ability to support multiple coding languages, api versioning, high performance achieved due to binary data serialization etc.

This blog is not related to introduction of gRPC, for that we have many other links like this one gRPC Intro

In this blog I want to share my learnings during my recent project in gRPC. In my project I am having a file getting streamed from one service to another and vice-versa. A sample scenario will be conversion of JPG to PNG where a JPG file is streamed to the server which converts it and sends back a PNG file.

1. Which one will you choose

First question that you need to get answer while you are reviewing someone's code is what type of gRPC service flavor did they opt for and why. Take a minute to think about our scenario, what do you think should be an ideal choice?

For our scenario we need to send file bytes and receive them so preferred way should be bi-directional streaming. This will give you a flexibility to break the file into chunks of bytes and send it to the server. You can either monitor the network transmission time or performance through such mechanism.

So having a chat with the author regarding the choice of service and getting to know why he/she didn't choose the other types is a good way to start code reviewing.

2. Follow TDD


An industrial way to write code in production is begin with unit tests. TDD (Test data driven) development has proven not only to be efficient in producing less bugs but also has proven to be a good way of understanding the code for a new pair of eyes.

This can help you as a code reviewer to understand the problem in hand and give reviews accordingly.

In order to write efficient unit tests, note we are creating a channel to talk to the grpc service from client. A test should not be complicated in the sense of creating a channel and stub , processing it  and eventually cleaning it. gRPC provides few ways through which you can create mocks of such channel and stubs seamlessly.

Take a look at this example provided by them. 

/*
* This rule manages automatic graceful shutdown for the registered servers
and channels at the end of test.
*/
@Rule
public final GrpcCleanupRule grpcCleanup = new GrpcCleanupRule();

Creating a stub for tests should use such channel in order to prevent the hassle of graceful shutdown handling code

GreeterGrpc.GreeterBlockingStub blockingStub = GreeterGrpc.newBlockingStub(
   // Create a client channel and register for automatic graceful shutdown.grpcCleanup.register(InProcessChannelBuilder.forName(serverName).directExecutor().build()));

Talking about the stub takes us to the next point which one should keep in mind while code reviewing

3. Deadlines


Indeed one should not be missing deadlines :) In world of gRPC deadline is considered to be timeouts. There is an emphatic statement at the start of this blog which I am sure will keep you awake during those sleepless nights of gRPC :)

In the earlier example we saw how to create a stub, if the author is creating the stub in a similar way there should be a comment for him/her to think about deadlines

response = blockingStub.withDeadlineAfter(deadlineMs, TimeUnit.MILLISECONDS).sayHello(request);
Monitoring deadlines often can help understand various issues which are due to external factors like network, instance shutdown etc.

4. Stubs


We have been talking about stubs, and this is the next thing as a code reviewer you should consider. gRPC provides 2 ways to create stubs blocking and non/blocking. Details at here . If you happen to see a blocking gRPC stub ask the author from where it should get invoked. If that is a UI feature then there is a big red flag waving in front of that code. 

As we already know Asynchronous actions are the preferred way to do UI flow creation unless there is a dire need to have a blocking action. 

While code reviewing this is a critical observation that you need to make and discuss the consequences with the author.

5. onError



@Overridepublic void onError(Throwable t) {
logger.log(Level.WARNING, "Encountered error in routeChat", t);
}

gRPC StreamObserver response comes with onNext, onComplete and onError scopes. onNext and onComplete is having a strict binding with your custom logic. But onError scope is interesting and should be considered for code reviewing.

This gets invoked whenever there is an error in server side. While debugging errors should be logged both on client and server side, but there are some scenarios when you don't throw specific exception to client because of information disclosure (security reason). In such cases it is very imperative to understand how the user is handling the error and how can you monitor for such exceptions.

6. How to monitor for such exceptions


Monitoring is the next crucial thing which the author should be thinking about. In order to have good monitoring one should be logging some kind of metric counter in scenarios like onError or onCompleted.

Prometheus provides an excellent way to create metrics which can help track errors on success and can help project in a dashboard. Take a look at the different types of counters they provide at here

Here is a typical dashboard which I have for my image conversion service 

Dashboards like this not only can help monitor your service but also can help you create alert notifications in case something goes bad.

Conclusion


I still consider myself newbie to the world of gRPC, I am capturing the learnings which I got during my project. Will look forward to the community to highlight any points I have missed which you feel can be crucial while reviewing for gRPC code. 

Hope to get your feedback on my understanding.

Sayonara for now....

Comments

Post a Comment

Popular posts from this blog

Firebase authentication with Ionic creator

Big Data - SWOT Analysis

LINKEDIN api call using NODE.JS OAUTH module