devLap

Stop Wasting Hours on "Project Setup": How I Automated Production-Ready Go APIs

go dev.to

Why I built a CLI to bridge the gap between "Hello World" and a production-ready microservice in 60 seconds.

The "Boilerplate Tax"

As a backend engineer, I noticed a recurring pattern. Every time I started a new service, I spent the first few hours doing manual labor that had nothing to do with business logic:

  • Setting up Structured Logging (Zap) with request correlation IDs.
  • Configuring Prometheus Metrics and health-check probes.
  • Hardening Security Headers (HSTS, CSP, XSS protection).
  • Writing Dockerfiles with multi-stage builds and non-root users.
  • Setting up Database Migration runners.

This is what I call the "Boilerplate Tax." It kills momentum and, worse, it leads to inconsistencies across teams. I wanted a tool that didn't just give me folders, but a production-ready foundation.

Introducing Goforge 🚀

Goforge is a CLI tool built for Gophers who value speed without compromising on engineering standards. It scaffolds a complete API based on Clean Architecture principles.

🎯 Key Features:

  • Framework Choice: Toggle between Fiber (for high performance) and Gin (for a massive ecosystem) using simple flags.
  • Security First: Integrated middleware for security headers and non-root Docker builds.
  • Observability: Built-in Prometheus /metrics and Zap JSON logging.
  • Ops Ready: Pre-configured PostgreSQL, Redis, and golang-migrate support.

Why Goforge? (The Architectural Perspective)

In the Go community, there is a constant debate between "Standard Library" purists and "Framework" users. While the standard library is powerful, modern cloud-native development requires significant "plumbing."

I designed Goforge to be opinionated where it matters (Security and Observability) but flexible where you need it (Business Logic).

1. Observability is Not Optional

In a distributed system, you can’t manage what you can’t measure. Goforge includes Kubernetes-ready /health/live and /health/ready endpoints out of the box.

2. The Multi-Framework Paradox

One of the hardest decisions is picking a framework. Goforge allows you to choose your engine while keeping the internal structure (Handlers -> Services -> Repositories) identical.

3. Developer Experience (DX)

I’ve included a comprehensive Makefile to ensure a "zero-config" local development experience:

make up  # Spins up API, PostgreSQL, and Redis in Docker
Enter fullscreen mode Exit fullscreen mode

How to Get Started

Option 1: Go Install (Recommended) 

go install github.com/viveksharma/goforge@latest
Enter fullscreen mode Exit fullscreen mode

Option 2: Download Binary

Download pre-built binaries from the Releases page.

Option 3: Install from Latest Main 

git clone https://github.com/vviveksharma/Goforge-CLI.git
cd goforge
make install
Enter fullscreen mode Exit fullscreen mode

This installs the latest development version to $GOPATH/bin (usually ~/go/bin).

Option 4: Build from Source 

git clone https://github.com/vviveksharma/Goforge-CLI.git
cd goforge
go build -o goforge ./cmd/goforge
sudo mv goforge /usr/local/bin/
Enter fullscreen mode Exit fullscreen mode

Then, forge your first production service:

# Create a Fiber-based API
goforge create payment-service --server fiber

cd payment-service
make up
Enter fullscreen mode Exit fullscreen mode

Goforge is open-source and MIT licensed. I’d love for you to try it out, break it, and help me build the ultimate starting point for Go developers.

Check out the repo and give it a star! ⭐
👉 https://github.com/vviveksharma/Goforge-CLI

Source: dev.to

arrow_back Back to Tutorials