Gin

A high-performance HTTP web framework for Go. Thin wrapper around net/http with a familiar middleware chain, route grouping, and JSON helpers. The de-facto default in Go web tutorials and a common choice in production.

Why it shows up everywhere

• Middleware chain via “chain of responsibility”: r.Use(authMiddleware, loggingMiddleware) — each middleware is just func(c *gin.Context) calling c.Next() to pass through.
• Route groups: scope middleware to a path prefix (v1 := r.Group("/v1"); v1.Use(...)), which is how the source article structures versioned APIs.
• Context object: gin.Context carries request, response writer, query/body parsers, and a per-request key/value bag — easy bridge for auth claims and request IDs.
• Performance: built on httprouter, comparable to bare net/http for routing.

Trade-offs vs alternatives

Choice	When
Gin	You want the Spring/Express ergonomics — middleware, groups, JSON helpers — without thinking
chi	You want Gin-shaped routing but built around net/http.Handler interfaces (fully composable with the standard library)
echo	Roughly equivalent to Gin, slightly cleaner API surface, smaller community
net/http + small router	Maximum control, no framework lock-in — what the standard library encourages now that http.ServeMux got patterns in Go 1.22
fiber	Built on fasthttp; not net/http-compatible, breaks middleware portability

For new kulify Go services, chi is often the better long-term choice (works with any http.Handler-aware tooling), but Gin is a defensible default if the team already knows it.

Pattern: Gin in go-layered-architecture

Handlers are methods on a struct that holds a Services interface:

type handlers struct {
    srv services.Services
}

func (h *handlers) GetUser(c *gin.Context) {
    user, err := h.srv.GetUser(c.Request.Context())
    if err != nil { ... }
    c.JSON(200, user)
}

// route wiring
v1 := r.Group("/v1")
v1.Use(middleware.TokenAuthentication())
v1.GET("/users/:id", h.GetUser)

Middleware composes left-to-right; c.Next() in middleware is what advances the chain.

kulify usage

• katastar uses standard net/http + handler functions, not Gin. If a refactor adds middleware composition pain, Gin or chi is the most straightforward upgrade.
• No other kulify project currently uses Gin.

Related

• go-layered-architecture — Gin’s middleware chain is what makes the Handler layer ergonomic
• gorm — common companion ORM in the same stack
• mockery — mock the Services interface, not the Gin handler itself