Production Go services: typed errors, consumer-side interfaces, and tests that need no database
go
dev.to
Every new Go service I start seems to begin with the same two weeks: wiring error handling, deciding where interfaces live, setting up tests that don't require Docker to be running, graceful shutdown, migrations... None of it is hard. All of it is decisions, and decisions cost more than code. This post walks through the three decisions that pay off the most, with working code. Everything here comes from go-service-kit, an MIT-licensed starter I open-sourced — but the patterns stand on their own