tag: Go

As a developer who works with Go in my day-to-day development, I constantly struggle with third party packages or tools which bring in a lot of dependencies. This is especially true when you’re trying to keep your project dependencies up to date, while dependabot, and other security software, is screaming about vulnerabilities in dependencies of dependencies. This is especially a problem with two common packages I use: Any HTTP adaptor package, which ships with integrations for multiple server packages, such as Gin, Echo, and others. Any package which uses docker to test with containers. Projects which include examples with their own dependencies. To break this cycle in my own projects, and packages I publish privately in work projects, I have adopted the use of Go workspaces, which allows me to create a monorepo broken up into multiple packages, and then publish one or more of these packages. ...

Assuming you read my Starting a Go Project post you should have the starting point for a minimal go web service. For your first project it is easier to keep all your code in one folder, in the base of your project, but at some point you will want to restructure things, this is done for a few of reasons: Having everything in one folder results in a lot of inter dependencies in the code. Reuse outside the project can be difficult as the code is only designed to be used in one package. It is impossible to have more than one binary, as you can have only one main method. This post will provide an overview of the structure I follow in my Go projects when building web services. ...

Given the changes with Go Modules I wanted to document a brief getting started for Go projects, this will focus on building a minimal web service. Before you start you will need to install Go, I recommend using homebrew or for ubuntu users Golang Backports, or as last resort grab it from the Go Downloads page. So this looks like this for OSX. brew install go Or for ubuntu we add the PPA, then install golang 1.14 and update our path. ...

I have been looking into the Versioned Go Command which was released recently by Russ Cox. In summary this project is a pretty rethink of how golang retrieves and stores packages used to build applications, and more specifically how versioned modules are introduced while retaining reproducible builds. The highlights, and standout features for me are as follows: Adds intrinsic support for versioning into the go command. Includes a few new sub commands such as vendor and verify Incorporates a lot of new ideas around the storage and management of golang modules, which seems to correlate to something akin to a github project. Note there is support for more than one module in a repository but the general idea is one. Adds a new mechanism to retrieve and cache modules in zip files, which will supersede the current source repository. Adds a new proxy mechanism, enabling organisations to provide a mediated, verified module server to developers. But probably the biggest change is the move away from the much maligned $GOPATH, this will as far as I can tell be deprecated over time. Developers will create their projects outside of the $GOPATH, using a file named go.mod to provide a pointer to the projects namespace. ...