Developer Tools Thursday #1 - Blueprint for Go
This week I found a tool which generates a Blueprint for your Go project. It makes creating a well-organized Go project easier.
Yesterday I started a new post series with the Weekly Optimization, and today we start the Developer Tools Thursday. With the Developer Tools Thursday, we keep you updated about cool new tools to improve your developer experience.
Improving the own developer experience is crucial to staying motivated and increasing productivity over time. Most developers love automations and I do too. Whenever possible, I try to automate my things around me.
Go Blueprint
Let's start with the first one. In my previous Go projects, my project structure became quite a challenge very fast. It is not really a Go thing because most projects in all languages get messy over time. In go starting, an organized project from scratch was not as easy as I would like. Today I found a tool which might help with that. Its Go Blueprint.
What is Go Blueprint?
It is a simple tool with two components. One is the website which generates a command and the second is the CLI that you can run on your device to generate the project. I really like the approach of having a configurator to have a very fast start into developing. You could compare it to Java Spring Boot, which is almost the same, but Spring Boot is more advanced.
You can also use go-blueprint create to generate a project in the terminal. Being able to choose between opening a website or doing it in shell is great. This gives you the decision based on your workflow.
What's the purpose?
Go is very good for a microservice architecture, and I think this boosts this aspect a little more. Generating a needed service very fast and not having to set up every file always again could result in a good approach to make it more efficient. Microservice architectures are most of the time not very efficient from the developer perspective. This is reasoned by the overuse of such things. In small teams, the benefit of a microservice approach is minimal but the more work in maintaining multiple projects is sometimes huge.
I think in small teams, a good purpose will be the excluding of important but not context-based functions into a microservice and save complexity or gain performance in the monolith. With Go Blueprint this just got easier.
