Tag Golang
I like having the core logic of our application free of distractions like too many technical “details” like logging or generating metrics. Of course, sometimes it’s hard to avoid it. I found in many projects a situation where we put the logger very deeply inside of the code. At the end of the day, we had the logger almost everywhere. In tests, we had to provide the mocked implementation everywhere as well. In most cases, the logger is a redundant dependency. In this article, I’ll argue that we should have the logger only in top-level functions.
Sometimes, we may want to use a library but a slightly modified version. It happens very often when we develop the library but test it in the context of an application. Go has a handy mechanism in go modules that can help us with it.
To make it work, we have to clone the library somewhere near the target project and run the following command in the application’s folder.
go mod edit -replace github.com/my/library ../path
The path can be both relative (to the application root folder) or absolute. The go.mod file will be edited as follows.
gRPC supports authentication. Adding it to your project is simple. All you have to do is configure it with just a few lines of code. One of the authentication types that gRPC supports is SSL/TLS. From the server-side, the code looks like this:
creds, err := credentials.NewServerTLSFromFile(certFile, keyFile)
if err != nil {
// handle the error - no ignore it!
}
s := grpc.NewServer(grpc.Creds(creds))
The client has to update the code as shown below.
creds, err := credentials.NewClientTLSFromFile(certFile, "")
if err != nil {
// handle the error - no ignore it!
}
conn, _ := grpc.Dial("localhost:50051", grpc.WithTransportCredentials(creds))
But, from where take the certificate? One of ways is using the openssl.
Programs should be written for people to read, and only incidentally for machines to execute - Abelson and Sussman
It is one of the most popular questions. You can find on the Internet attempts to answer this question. I’ve had concerns if I’m designing my packages or even the whole project correctly. Today, I’m not 100% sure about that!
Some time ago, I had the pleasure to meet Robert Griesemer (one of Go’s authors) in person. We asked him this question: “How to structure Go code?”. He said: “I don’t know.” - It’s not satisfying, I know. When we asked him about how he designs his code Robert said that he always starts with a flat structure and creates packages when he has to. That’s much more concrete.
Some time ago, I found a Stack Overflow question. The author had a problem with understanding why the context from the request he’s using is canceled. I remember that I had a similar situation in the past: I used the context from the HTTP request and tried to use it in background operation and return the response to the user before it was finished. This issue comes from not understanding how the context is used in the http.Server struct. I want to save you from similar surprises. I described it in this article.
Writing linters is simple. I was surprised how it’s easy to write a Go linter. Today, we’ll write a linter that will calculate the cyclomatic complexity of the Go code.
What is cyclomatic complexity?
Cyclomatic complexity is a software metric used to indicate the complexity of a program. ref
The idea is simple - every time we find any control flow statements we increase the complexity by one. I know I oversimplified it a bit but I don’t want to overwhelm you with unnecessary details.
In this article, I explain how you can detect if the interface you’re using is getting too big and requires splitting into smaller ones. Smaller interfaces help to improve the maintenance and readability of the code. What’s more, it helps with understanding the code.
Interfaces in Go are different than those known in Java, c#, PHP etc. In those languages you define interfaces up-front. In other words, at the moment of creating a class you need to know how the class will be used. In Go things are different. You can create a struct with as many functions you want and the user of if can define only a sublist of methods he needs. It’s very powerful tool. But sometimes we still can create too big interfaces. The list above should help you find interface segragation issues in your code.
The context package in Go is quite simple and well-known. On the other hand, there are some misunderstandings while using it. Today, I’ll try to explain all the most popular concerns and make more clear when and how use the Context.
Let’s start with what the context is.
Package context defines the Context type, which carries deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes. ref: https://golang.org/pkg/context/
Go has plenty of different web frameworks. When you are faced with choosing a framework for the first time, it may turn out to be quite a challenge to choose the best one. This article is intended to help you choose the best one. It is full of personal judgments that you may disagree with. However, I believe you will find it most helpful.
Martini
The first framework is Martini. Honestly, it shouldn’t be here as it’s been under development since 2017. However, I added it because I found it on other compilations. Just don’t use it :)
In Go, we can refer to variables using value or pointers. Sometimes, it’s hard to answer which approach is more suitable.
At the first place, you should learn about general rules. Value semantic should be used every time when copying the value make sense in the logic of your code. For example, every value object should be passed by value. If you have a struct Money then it’s possible (and also make sense) to have, at the same time, multiple 10$ in your code. There’s no such requirement that only one person can have the same amount of money.