When I first entered the world of Go, I had trouble thinking what are the best use-cases for the language. I knew that I could build backends for web applications or microservices, but I've always thought that it's perfect for building CLI tools. Some time ago I came across a library that makes building those in Go super easy. Let's build such a tool using Steve Francia's cobra.
Writing technical documentation for the application is often more difficult, than creating its code. We, developers, know our craft very well, but when it comes to leaving some signs of how things work, how to use them, etc., we are surprisingly ineffective. On the other hand, when we are about to use some external dependency, we'd love to see examples of how it can be inserted into our code. How do we do that in Go?
One of the things that I missed the most, apart from generics, when coming to Go while having Java background was the lack of inheritance. In JVM it was pretty simple, as you can define a parent and child classes, then have a common behavior present all the children objects. This is not the case in Go, and I had to learn how to work around this. Here, we don't have inheritance, we have the composition, and for that, we have a pretty useful technique called embedding structs.
One of the things that Go community is the proudest of is the toolchain that is shipped alongside the language. Apart from dependency vendoring (this is in progress), you can run the whole show of taking your source code, testing it, cross-compiling, all the way to building a single binary output file. One of the lesser known tools that you should get familiar with is the one that "just" lists stuff...
Recently at work, we ran into an interesting problem (challenge?). We are running our microservice architecture on Kubernetes, and we keep all of our internal communication over gRPC. Even though we are able to scale up particular parts of our applications, we started to face some bottlenecks. After a while, we realized, that even though we have multiple instances of some parts, we have one active gRPC (HTTP/2) connections between each service, which results in a single connection between particular pods.
In the previous part of the tutorial, we've generated resource endpoints for managing skills data to be displayed on a resume page. However, the problem was that anyone who could see the page, might potentially access those endpoints and edit the data. In this post, we'll add a not-so-complicated authentication using an external provider (Github) to restrict access to those pages.
We've already created a dynamic business-card website, so what can be added now? Actually, we've connected it to the database but haven't used the feature, that makes managing data really easy and fun. If you'd like to have a neat interface to view and edit stuff from the database, then you'll love Buffalo resources.
The difference between websites and web applications is that the app does display dynamic data, while a simple site can just present some static values. So far we've developed a site because nothing can ever change there without us affecting a source code. It's time to change that and finally display something from the database.
This post is a short story about a bug that we found a couple of days ago in our backend application. The bug that originated with a simple mistake in an SQL statement, but it was the one we'd expect to be handled by the database itself. Some time ago we considered ditching MySQL for Postgres, and as a matter of fact, that switch would have saved us this time. Let's see how both products handle something we can call "casted joins".
Since we started working on our business-card website using Buffalo, we might have extended our business to serve clients from all over the world. That's great, but how can we do that if our website is in English only? We definitely need to allow users to use different languages and provide appropriate content for that.