We've already seen how you can implement a simple queue in Redis using a list key and smart pushing and popping the elements. But is there any better, cleaner and more suitable way to do such a thing? Does Redis provide any other possible approach? You bet! Enter Pub/Sub.
As you probably already know, Redis goes well beyond getting and setting values. One of the less often used features in the database is the ability to implement a pretty simple task queue and share it between a producer and a consumer. Let's take a look how you can do that in a few steps.
Having implemented counting in Redis using one counter per value seems the way to go, as long as we know about all the things we want to keep track of. Once we want to monitor some more dynamic structures, this quickly becomes an issue. There is, however, a way to do this smart. We need to know what are hashes.
Being one of the most popular key-value databases, Redis has been perceived my the majority of their users as a dictionary that is used for two operations: setting values and getting them. What is less popular, yet very useful is the way we can keep track of some count values, by simply incrementing them. Let's implement a small "pagehit" summary page then.
Since its initial release in 2009, Redis has become one of the most popular NoSQL solutions and almost a synonym for a key-value database. Thanks to being around for some time, there are a few use cases that it is more than suitable for. One of them is a persistent store for users' sessions in a web application. While it has already been implemented and available using various open source libraries, let's see if we can do it by ourselves.
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.