The flickering cursor mocks you. Another new Go service, another dive into the same old rabbit hole of setting up logging with trace IDs, wrangling configuration, and stitching together a Kafka consumer that won’t immediately fall over. For many seasoned Go developers, this scene is grimly familiar. It’s the unglamorous, time-sucking ritual that precedes the actual interesting work.
And that’s precisely the pain point a new open-source project, rock288/go-mongo-<a href="/tag/boilerplate/">boilerplate</a>, seeks to alleviate. Launched by an engineer tired of repeating himself, this template isn’t just another grab-bag of libraries. It’s a curated, opinionated collection of the “boring but essential” pieces that have, through five years and six services, coalesced into a battle-tested foundation. Think observability, strong retry mechanisms, dead-letter queues, SSRF-safe HTTP clients, health check splits, and yes, even graceful shutdown—all baked in.
Why does this matter? Because the initial setup of a service, particularly in a language like Go that values explicitness, can be deceptively complex. The original author recounts the familiar litany: the slog handler auto-injecting trace_id, the config library maze, the finicky event.CommandMonitor for MongoDB that can easily leak memory, the Kafka consumer with its attendant retry and DLQ logic, patching HTTP clients against SSRF vulnerabilities, separating /healthz from /readyz, and the perennial struggle to keep golangci-lint, mockery, and Wire in harmony. Most existing boilerplates tackle one or two of these; this one aims for the whole messy suite.
The internal/ Layout Reimagined
The most immediate architectural departure is the project’s layout. Forget the tired models/, controllers/, services/ directories that devolve into a grep nightmare. Instead, go-mongo-boilerplate embraces a feature-centric internal/ directory. Each feature gets its own subdirectory, housing its models, repositories, services, handlers, and routes. Cross-feature communication is strictly mediated through exported interfaces, preventing brittle, concrete type dependencies. Anything that doesn’t belong to a single feature—config, logging, database clients, HTTP servers—resides in internal/platform/. This structure promises to scale gracefully, keeping related code together.
Most Go boilerplates on GitHub solve one of these. None of the ones I found solved all of them in a way that felt opinionated rather than kitchen-sink-y.
Adding a new feature is reduced to a single command: make scaffold name=Order. This isn’t mere scaffolding; it’s a distilled process that clones a template feature directory, performs identifier renames, and presents a clear checklist. The author claims that going from zero to a working GET /orders endpoint takes roughly ten minutes. That’s a significant acceleration over hand-rolling the infrastructure.
Taming MongoDB’s Tracing Dragon
Observability, especially for databases, is a persistent challenge. While the go.mongodb.org/mongo-driver/v2 has matured, official OpenTelemetry instrumentation remains conspicuously absent. This is a gaping hole that often leads to production issues. The boilerplate tackles this head-on with a custom event.CommandMonitor. It meticulously tracks MongoDB command durations, linking them to spans. But here’s the crucial detail: unclosed commands—think network drops or server restarts—can become memory leaks. The solution involves a janitor goroutine, actively purging stale entries.
This custom monitor is where the author feels many projects stumble.
```go // internal/platform/database/mongo_otel.go client
