Go

Introduction With the advent of distributed applications, we see new storage solutions emerging constantly. They include, but are not limited to, Cassandra, Redis, CockroachDB, Consul or RethinkDB. Most of you probably use one, or more, of them. They seem to be really complex systems, because they actually are. This can’t be denied. But it’s pretty easy to write a simple, one value database, featuring high availability. You probably wouldn’t use anything near this in production, but it should be a fruitful learning experience for you nevertheless....

Practical Golang: Getting started with NATS and related patterns Introduction Microservices… the never disappearing buzzword of our times. They promise a lot, but can be slow or complicated if not implemented correctly. One of the main challenges when developing and using a microservice-based architecture is getting the communication right. Many will ask, why not REST? As I did at some point. Many will actually use it. But the truth is that it leads to tighter coupling, and is synchronous....

Introduction Most apps we make need a means of communication. We usually use JSON, or just plain text. JSON has got especially popular because of the rise of Node.js. The truth though, is, that JSON isn’t really a fast format. The marshaller in Go also isn’t that fast. That’s why in this article we’ll learn how to use google protocol buffers. They are in fact very easy to use, and are much faster than JSON....

Introduction In this part we’ll be creating a simple middleware you can easily apply to your handlers to get authentication/authorization. Middleware like this is an awesome way to add additional functionality to your Go server. Here we will only do authorization as we will only ask for a password, not a login. Although if you want, then you can easily extend this system to any authentication/authorization you’d like. Implementation We will mainly use the stdlib, and will use cookies to remember who’s already logged in....

Previous part Introduction In this part we will finally finish writing our application. We will implement the last two services: The Worker The Frontend The Worker The worker will communicate with the Master to get new Tasks. When it gets a Task it will get the corresponding data from the storage and will start working on the task. When it finishes it will send the finished data to the storage service, and if that succeeds it will register the Task as finished to the Master....