Goxygen: The Full-Stack Generator That Cuts Through Boilerplate Hell

Hook

Setting up a modern full-stack project with Go, React, Docker, and PostgreSQL typically takes 2-3 hours of copying configs and wrestling with CORS. Goxygen does it in 30 seconds with a single command.

Context

Every Go web developer has been there: you have a great idea for an application, but before writing a single line of business logic, you're stuck configuring Docker containers, setting up database connections, wrangling CORS policies, and creating the twentieth iteration of your personal boilerplate. The JavaScript ecosystem solved this years ago with create-react-app and similar tools, but the Go ecosystem has remained fragmented. While frameworks like Buffalo offer full scaffolding, they lock you into heavyweight, opinionated architectures.

Goxygen emerged to fill this gap with a different philosophy: generate a clean, minimal full-stack project structure without imposing a framework. Created by Alex Shpota, it takes the approach of "just enough" scaffolding—giving you a working Go REST API, your choice of frontend framework (Angular, React, or Vue), database integration (MongoDB, MySQL, or PostgreSQL), and production-ready Docker configurations, then getting out of your way. The tool itself doesn't even require installation; it leverages Go 1.16+'s ability to run modules directly, making it truly zero-friction for developers who already have Go installed.

Technical Insight

Under the hood, Goxygen is remarkably straightforward—it's essentially a sophisticated template engine wrapped in a CLI. The entire generator is built using Go's standard text/template package, with project templates stored as embedded files. When you run go run github.com/shpota/goxygen@latest init --frontend react --db postgres my-project, the tool copies and processes template files, substituting project names and configurations based on your selections.

The generated architecture follows a clean separation of concerns. Your project structure looks like this:

my-project/
├── server/          # Go backend
│   ├── db/          # Database connection logic
│   ├── model/       # Data structures
│   ├── web/         # HTTP handlers
│   └── main.go
├── webapp/          # Frontend (React/Vue/Angular)
│   ├── src/
│   └── package.json
├── docker-compose.yml
├── docker-compose-prod.yml
└── Dockerfile

The Go backend uses a minimal dependency approach—no heavy frameworks, just the standard library plus a database driver and github.com/rs/cors for handling cross-origin requests. Here's what a typical generated handler looks like:

package web

import (
    "encoding/json"
    "net/http"
    "my-project/model"
    "my-project/db"
)

type Handler struct {
    storage db.Storage
}

func (h *Handler) GetTechnologies(w http.ResponseWriter, r *http.Request) {
    technologies, err := h.storage.GetTechnologies()
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(technologies)
}

The database layer uses interfaces for abstraction, making it easy to swap implementations or add mock testing later. For PostgreSQL, the generated code uses lib/pq with standard database/sql, while MongoDB projects get the official MongoDB driver. Importantly, the database initialization scripts are included—when you run docker-compose up, your database is seeded with sample data, so you can immediately see the full stack working.

What makes Goxygen particularly clever is how it handles the frontend-backend integration. The development Docker Compose file mounts both server and webapp directories as volumes, enabling hot reload for both Go (using Air in the container) and your frontend framework's dev server. The production configuration takes a different approach—it builds the frontend into static assets and serves them directly from the Go binary using http.FileServer:

fs := http.FileServer(http.Dir("./webapp/build"))
http.Handle("/", fs)

This means your production deployment is a single binary plus a database container—no separate nginx configuration or static file hosting needed. The generated Dockerfile uses multi-stage builds to keep the final image small, compiling both the frontend assets and Go binary in separate stages before combining them.

The tool's installation-free execution model deserves special attention. By using go run github.com/shpota/goxygen@latest, you're telling Go to download the module, compile it temporarily, and execute it—all without cluttering your system with another globally installed CLI tool. This is a brilliant use of Go's module system that more tools should adopt.

Gotcha

Goxygen's simplicity is both its strength and limitation. The generated projects are intentionally minimal, which means you're getting a basic CRUD application scaffold—not a comprehensive starter kit with authentication, authorization, API documentation, or testing infrastructure. If you need JWT authentication, role-based access control, or OpenAPI/Swagger documentation, you'll be implementing those from scratch. The tool offers no flags for "add authentication" or "include testing setup," so every generated project starts from the same baseline.

The stack choices, while covering common scenarios, are restrictive. If your team uses Svelte, Next.js, or prefers SQLite or Redis, Goxygen isn't an option. There's no plugin system or way to extend the generator with custom templates. The three-by-three matrix (three frontends, three databases) gives you nine combinations, but stepping outside those boundaries means you're back to manual setup. Additionally, the generated Go code doesn't include any ORM or query builder—you're working with raw SQL or MongoDB queries, which some teams might find too low-level for rapid development. The project structure is also somewhat opinionated toward monolithic deployments; if you're building microservices or want separate repositories for frontend and backend, you'll need to restructure immediately.

Verdict

Use if: You're starting a new full-stack project or MVP where Go + SPA + SQL/NoSQL fits your architecture, you want production-ready Docker configurations without manual setup, you prefer minimal dependencies and standard library approaches over heavyweight frameworks, or you're teaching/learning Go web development and need a working reference implementation quickly. It's particularly excellent for hackathons, prototypes, and internal tools where time-to-first-working-version matters more than extensive customization. Skip if: You need a technology stack outside the nine supported combinations (like Svelte, Next.js, or SQLite), you require generated authentication/authorization/testing scaffolding out of the box, you're building microservices where the monolithic structure doesn't fit, or your organization has established project templates with specific patterns and libraries. Also skip if you're building a complex application where the minimal scaffold would need immediate significant refactoring—at that point, starting from your own battle-tested templates makes more sense.