Book Image

gRPC Go for Professionals

By : Clément Jean
Book Image

gRPC Go for Professionals

By: Clément Jean

Overview of this book

In recent years, the popularity of microservice architecture has surged, bringing forth a new set of requirements. Among these, efficient communication between the different services takes center stage, and that's where gRPC shines. This book will take you through creating gRPC servers and clients in an efficient, secure, and scalable way. However, communication is just one aspect of microservices, so this book goes beyond that to show you how to deploy your application on Kubernetes and configure other tools that are needed for making your application more resilient. With these tools at your disposal, you’ll be ready to get started with using gRPC in a microservice architecture. In gRPC Go for Professionals, you'll explore core concepts such as message transmission and the role of Protobuf in serialization and deserialization. Through a step-by-step implementation of a TODO list API, you’ll see the different features of gRPC in action. You’ll then learn different approaches for testing your services and debugging your API endpoints. Finally, you’ll get to grips with deploying the application services via Docker images and Kubernetes.
Table of Contents (13 chapters)
10
Epilogue

Canceling a call

When you want to stop a call depending on certain conditions or interrupt a long-lived stream, gRPC provides you with cancellation functions that you can execute at any time.

If you have worked with Go on any distributed system code or API before, you probably saw a type called context. This is the idiomatic way to provide request-scoped information and signal across the API’s actors, and this is an important piece of gRPC.

If you did not pay attention, up until now, we used context.Background() every time we made a request. In the Golang documentation, this is described as returning “a non-nil, empty Context. It is never cancelled, has no values, and has no deadline.” As you can guess, this alone is not suitable for production-ready APIs for the following reasons:

  • What if the user wants to kill the request early?
  • What if the API call never returns?
  • What if we need the server to be aware of global values (e.g., an authentication...