Managing multiple Kubernetes environments can be a bit tricky to juggle, especially if you want to make sure you don't deploy anything to production by mistake, or that you're looking on stage env logs to debug a problem that does not exist in prod (yet). It would be better to have some kind of notification what configuration is currently used by kubectl command. This is when I decided to create a flag in my terminal prompt.
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.
So far we've seen how to build a GraphQL API that serves the user with data stored in the databases. But what about making changes? With a few tweaks in the structure, we can achieve this as well. Let's take a look on things called mutations.
Building an API in GraphQL looks very easy, as you could have already seen based on two previous posts. The thing is that everything looks simple when no parameters are provided, right? Let's take a look at how to make our API just a bit more dynamic.
In the previous post, we've seen how easy it is to set up a simple GraphQL server in Golang. The problem is, that we have hardly done anything special, that would distinguish our API from one written for REST. It's time for something more advanced, that is nested objects and fetching them from different sources.
For a long time building an API (eg. for web applications) has become associated with REST. Meanwhile, less than two years ago, Facebook announced a technology they've been using for some time called GraphQL. It's an alternative way to provide data to the users, where each client can squeeze multiple queries into a single one.
Any web application that is targeted to more than one user is likely required to have some kind of authorization technique so that it can determine if given user can execute certain actions. The problem how to do this remains, despite dozens of years passed in software development world. One of the approaches, gaining much popularity recently are JSON Web Tokens. This short post shows how you can use them in your Golang application.