Logging is an integral part of any application. However, the correct location and use of the logger in the project structure raises questions even for experienced developers.

There are several ways of doing this, of which I give preference to one. I will explain why.

How to implement transaction management in a hexagonal microservice? How to keep the isolation of the application layer and the database adapter? In this article I will share my experience in solving this problem.

Hey, reader! Maybe you had tried go-swagger library so far. If yes, you may notice that sometimes it’s not so easy to use. And it may look a bit complicated to start using it. In this number of small articles, I will share my experience on how to make go-swagger more friendly. Let’s start. Handling requests in go-swagger By default, go-swagger generates a specific handler type for each endpoint in your Swagger scheme - that is, you will get a code-generated structure with all import parameters kindly parsed for you and a number of responders for each response type (with pre-generated structures as well).

We all love unit tests because they help us to keep our software workable. And we all hate them because they don’t appear magically - someone needs to write them. And when it comes to writing, it often takes a huge amount of time to cover the simplest cases. But I found my way to do that without pain (okay, with less pain). And I will share it with you like a simple illustrated guide.

There are many good approaches to handle configuration in a modern application. Now we use such things as configuration files, environment variables, command-line parameters, as well as CI configuration patterns and on-fly config file builds, remote config servers, specific mapping, and binding services and even more complex things. But the target is the same - provide the app with a configuration, which is fast to get and easy to use. But how to do that?

deploy a dockerized app to Heroku fast! Heroku is a beautiful service. Although it doesn’t support Kubernetes or give a so bright range of cloud infrastructure options, it still does a great job by hosting small applications (even for free). But the remote cloud configuration may be painful. It’s easy and nice until something goes wrong. It’s ok to dive into manuals and documentation, spend hours to understand how things work and so on.

Like many modern languages, Golang has built-in inline documentation support tool called godoc. To be honest, it’s awesome. It is a really great tool, that has a real impact on the everyday coding process. At least if you use plugins with function call tips as I do. But there is the big problem of the majority Go-projects that is tightly related to godoc but lays outside of it. The godoc is really cool.