go-tool-base

The underpinnings for any Go application that ships as a binary: command-line tools to start with, and (as more than half of what is built on it now proves) long-running services and local web UIs too. It standardises the boilerplate and wiring you end up writing in every Go project, and puts config, logging, self-update, a DI container and the rest straight at your fingertips. Highly opinionated, and it makes some calls people will disagree with, but it works, and it works really well. The CLI it ships with is a big part of that: keeping a Go app built, updated and maintained becomes almost trivial.

Generate an asymmetric RSA-4096 signing key inside AWS KMS with no export path, then sign releases by calling kms:Sign instead of holding the key.

Generating a Go command from a shell script or a plain sentence, and the repair agent that has to make the result build before you see it.

A checksum proves the bytes match the manifest, but says nothing about who wrote the manifest. Why self-update needs a signature instead.

Operational telemetry can be personal data, and a web service has no first-run prompt to ask on. So plumbing is not an answer.

Two telemetries with opposite consent defaults on one OTLP layer: consent-gated analytics for a CLI, implied-consent observability for a service.

Add OpenTelemetry traces, metrics and logs to a Go service with middleware and manual spans, and get one end-to-end trace through the gateway.

Generate an OpenAPI v3 document from an annotated proto file and serve it from the same HTTPS server with an embedded Stoplight Elements UI.

Replace a hand-written REST layer with grpc-gateway: add google.api.http annotations, generate the gateway, and delete the duplicate encoding.

Serve HTML from the same Go HTTP server using html/template and embed, baking templates and static assets straight into the binary.

Two ways to put REST on a Go service: a hand-written net/http ServeMux, and generated handlers from an OpenAPI spec with oapi-codegen.