Every Go team eventually has the router argument: stick with the standard library, or reach for a framework? When the answer is a framework, it’s usually Gin, the most starred HTTP framework in the Go ecosystem. The popularity is earned. Fast routing, a simple middleware model, and an API that stays out of your way.

Here’s what it gives you, and a couple of places it will bite you.

What makes Gin different?

Gin uses httprouter under the hood, which stores routes in a radix tree, so lookups stay cheap no matter how many routes you register.

Honestly though, raw speed is rarely why people pick it. Your database will be the bottleneck long before your router is. The real draw is the API: if you’ve used Express.js or Flask, you’ll feel at home within the hour.

Here’s a basic server:

package main

import (
	"net/http"

	"github.com/gin-gonic/gin"
)

func main() {
	r := gin.Default()

	r.GET("/ping", func(c *gin.Context) {
		c.JSON(http.StatusOK, gin.H{
			"message": "pong",
		})
	})

	r.Run(":8080")
}

That’s it. A working API in under 20 lines.

Middleware: where Gin shines

Middleware in Gin is refreshingly boring. You write a function that takes *gin.Context and calls c.Next() to continue the chain. No interfaces to implement, no registration ceremony.

Here’s a simple logging middleware:

func RequestLogger() gin.HandlerFunc {
	return func(c *gin.Context) {
		start := time.Now()
		path := c.Request.URL.Path

		// Process request
		c.Next()

		// Log after request completes
		latency := time.Since(start)
		status := c.Writer.Status()

		log.Printf("[%d] %s %s - %v", status, c.Request.Method, path, latency)
	}
}

func main() {
	r := gin.New() // No default middleware
	r.Use(RequestLogger())
	r.Use(gin.Recovery()) // Recover from panics

	// Routes here...
}

The gin.Default() function gives you logging and recovery middleware for free. In production I’d rather start from gin.New() and add exactly what I need, so nothing is logging in a format I didn’t choose.

The mental model is similar to how context works in Go - data flows through the chain, and each handler can inspect or modify it.

Route groups and versioning

Real APIs need structure, and route groups are how Gin provides it:

func main() {
	r := gin.Default()

	// Public routes
	public := r.Group("/api/v1")
	{
		public.GET("/health", healthCheck)
		public.POST("/login", login)
	}

	// Protected routes
	protected := r.Group("/api/v1")
	protected.Use(AuthMiddleware())
	{
		protected.GET("/users", listUsers)
		protected.POST("/users", createUser)
		protected.GET("/users/:id", getUser)
		protected.PUT("/users/:id", updateUser)
		protected.DELETE("/users/:id", deleteUser)
	}

	r.Run(":8080")
}

func getUser(c *gin.Context) {
	id := c.Param("id")
	
	// Fetch user from database...
	user := fetchUser(id)
	if user == nil {
		c.JSON(http.StatusNotFound, gin.H{"error": "user not found"})
		return
	}

	c.JSON(http.StatusOK, user)
}

The :id parameter comes straight out with c.Param("id"). No reflection gymnastics, no ceremony.

Request binding and validation

This is the feature that saves the most code in practice. Gin handles JSON binding with built-in validation:

type CreateUserRequest struct {
	Email    string `json:"email" binding:"required,email"`
	Password string `json:"password" binding:"required,min=8"`
	Name     string `json:"name" binding:"required"`
}

func createUser(c *gin.Context) {
	var req CreateUserRequest

	if err := c.ShouldBindJSON(&req); err != nil {
		c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
		return
	}

	// req is now validated and ready to use
	user := User{
		Email: req.Email,
		Name:  req.Name,
	}

	// Save to database...

	c.JSON(http.StatusCreated, user)
}

The binding tags come from go-playground/validator, so you get email validation, length checks and dozens of other validators without writing any of them yourself. Hand-rolling this against net/http gets old fast.

Common pitfalls

Two mistakes come up constantly in Gin code. The first is forgetting to return after sending an error response. Writing a response doesn’t stop the handler, so the rest of your code happily executes:

// Wrong - code continues after error
if err != nil {
	c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
}
// This still runs!
c.JSON(http.StatusOK, data)

// Right - return after error
if err != nil {
	c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
	return
}
c.JSON(http.StatusOK, data)

The second is goroutines. A *gin.Context is only valid for the lifetime of the request, so if you spawn a goroutine from a handler, copy the context first:

func handler(c *gin.Context) {
	// Copy the context for goroutine use
	cCp := c.Copy()
	go func() {
		// Use cCp, not c
		log.Println(cCp.Request.URL.Path)
	}()

	c.JSON(http.StatusOK, gin.H{"status": "processing"})
}

Should you use Gin?

My honest answer: not always. For a small service with a handful of endpoints, plain net/http is fine, and one fewer dependency is worth something. But the moment you find yourself hand-rolling route parameters, middleware chains and request validation, Gin starts paying for itself, and it keeps paying as the API grows.

When you outgrow the basics, the official Gin documentation covers custom validators, file uploads and HTML rendering.

Try it on the next API you build. Worst case, you’ll have a sharper opinion for the router argument.