This is the first article in a series dedicated to FSM usage in distributed system architecture. We will talk about domains, transactions, and sagas. But let's start with the basics.
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?
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...
Like many modern languages, Golang has built-in inline documentation support tool called
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.
There are many concurrent approaches to organize application configuration nowadays.
.yaml, configs, modern
.env and, of course, container environment. And don’t forget about CLI arguments! Am I missing something?