Exposing gRPC server in a form of HTTP API is pretty easy using grpc-gateway, but when it comes to returning errors, the default behavior is something that might be bothering us. Let's see how can we improve that.
Building a gRPC service is not that complicated, even if we want to add some security, custom interceptors and complex request or response messages. Unfortunately, it's still not as popular as we'd like, and most of the time we need to support HTTP as well. Building two identical APIs seems like a terrible idea, right? With gRPC Gateway you can save lots of time, so let's jump in.
Setting up communication between the server and its clients via gRPC is really simple, but what about the security? It's not that hard, either. Let's take a look.
In the previous post, we started looking on gRPC by generating code using protocol buffers. As important as that step was, it would not be quite that powerful without some actual use case, where we'd like to have the same structure created on both sides od communication. This blog post provides you with such example use case - let's see how you can build your first gRPC server and its client in Golang.
When building a microservice architecture, two of the most common approaches are a common messaging queue and HTTP APIs that are exposed and consumed by each element of the project. Despite those approaches being perceived as well-known and battle-tested, the community warmly welcomed another player to the game - gRPC. This is an introduction to this way of communication, and the story has, to begin with, a date with Protocol Buffers - something that sets gRPC apart.