// ABOUT
What is gopackx?
A small, curated collection of production-ready Go packages for backend developers. Built and maintained by a single developer — for now.
The mission
The Go ecosystem has two extremes: enormous frameworks that pull in half a dozen abstractions to do one job, and abandoned single-author repos with the last commit from 2019. Both are productive in the short term and painful in the long term.
gopackx sits in the middle. Each package is small enough to read in one sitting, opinionated enough to be useful out of the box, and maintained because I run it in services I get paged for. The bar for inclusion is simple: I have to be willing to depend on it myself.
There is no plan to be everything. There is a plan to be reliable for the four problems gopackx solves today, and to grow only when there's a clear gap I keep hitting in real work.
// PRINCIPLES
How we build
- 01
Zero magic
Every package in gopackx is built on the principle that you should be able to read the source and understand exactly what runs. No reflection-heavy abstractions. No global registries. No hidden goroutines spun up at import time.
When something goes wrong at 2am, you shouldn't have to spelunk through a framework to find the actual SQL or HTTP call. The control flow lives in your code, not in the library's.
- 02
Tested where it matters
Unit tests against mocks tell you the code compiles. Integration tests against real Postgres, real Redis, real SMTP, and real S3 tell you the code works. gopackx packages ship with both — and the integration suite is what gates a release.
If a behavior depends on a database transaction, a mocked transaction won't catch the bug. The migration tests run against real engines because they have to.
- 03
Stable APIs
Public surface area is small on purpose. Once a function is exported, breaking it requires a major version bump and a clear migration path in the changelog.
Internal refactors happen all the time. Breaking changes you have to chase across your service do not.
- 04
Documented for humans
Every package ships with a README that includes the why, not just the how. Godoc covers the surface; the README covers the decisions, the trade-offs, and the cases where you probably want a different tool.
Code without context is a puzzle. Documentation is the part that answers "why was it built this way?" — the part that AI-generated docs always miss.
// MAINTAINER
Behind gopackx
I'm Andrian. I've spent the last several years building backend systems in Go — payment rails, audit pipelines, notification fan-out, and the boring infrastructure that holds it all together. The kind of work where the metric of success is "no one paged me last week."
gopackx came out of a pattern: every new project, I'd reach for the same four libraries and find them either bloated, unmaintained, or subtly wrong for production. So I extracted my own. Each package here started inside a real service, was hardened against real traffic, and made it out only after I'd run it for at least one full quarter.
I write about backend engineering, Go internals, and the uncomfortable trade-offs you don't see in tutorials. If any of that sounds useful, the blog is where it lives.
Tech I work with
- Go
- PostgreSQL
- Redis
- Docker
- Kubernetes
- gRPC
- AWS
What's next
The roadmap is short on purpose. The next milestones are: a v1.0 cut for each package once the API has been stable for two consecutive minor versions, integration test matrices against the latest two Go releases, and a single new package focused on background job orchestration — only if I keep needing it across services. No expansion for the sake of expansion.
See public roadmapContribute
gopackx is open source under the MIT license. Bug reports, package ideas, and pull requests are all welcome — read the contributing guide first so we both save time.