I Chose Chi Over Gin for 60 API Endpoints. Here's Why I Don't Regret It.

Every Go web framework comparison post says the same thing: "Gin is the most popular, Fiber is the fastest, Echo is a good balance." Chi barely gets a paragraph.

I'm building a multi-tenant deployment platform in Go. The API has 60 endpoints across 12 route groups: account management, tenant CRUD, deployments, services, environment variables, custom domains, network rules, GitHub integration, registry credentials, real-time SSE events, admin tools, and health checks.

I chose Chi. Months later, I still think it was the right call. Here's why.

The Decision Point

When I started, the choice came down to Gin and Chi. I'd used Gin before and liked it fine. But three things pushed me toward Chi:

Chi handlers are just http.HandlerFunc. That's it. No custom context type, no framework-specific signature. Every handler I write looks like this:

func (s *Server) handleCreateTenant(w http.ResponseWriter, r *http.Request) {
    provider := middleware.GetProvider(r.Context())
    // ... business logic
}

Standard http.ResponseWriter. Standard *http.Request. If I ever needed to rip out Chi and drop in something else or just use the standard library's http.ServeMux, my handlers don't change. With Gin, every handler takes *gin.Context, which means every handler is married to Gin.

Chi's middleware is just func(http.Handler) http.Handler. The standard net/http middleware signature. I can use any middleware from the Go ecosystem without an adapter. Rate limiters, CORS handlers, logging middleware, if it works with net/http, it works with Chi. No gin.HandlerFunc wrappers needed.

Chi nests routes with r.Route(), not method chains. This matters when you have 60 endpoints.

How the Router Actually Looks

Here's a simplified version of my real router. The full thing is in internal/api/router.go:

func NewRouter(deps Deps) http.Handler {
    r := chi.NewRouter()

    // Global middleware — runs on every request
    r.Use(middleware.RequestID)
    r.Use(middleware.Logger(deps.Logger))
    r.Use(middleware.Recovery(deps.Logger))
    r.Use(cors.Handler(cors.Options{
        AllowedOrigins: []string{"https://*", "http://*"},
        AllowedMethods: []string{"GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS"},
    }))

    // Health — no auth, no rate limiting
    r.Get("/healthz", handleHealthz)
    r.Get("/readyz", handleReadyz(hc))

    // Public — rate limited by IP, no auth
    r.With(rl.IPMiddleware(10)).Post("/api/v1/waitlist", srv.handleJoinWaitlist)

    // Internal — service-to-service, shared secret
    r.Route("/api/v1/internal", func(r chi.Router) {
        r.Use(srv.internalAuth(deps.InternalAPIKey))
        r.Get("/tenants/{id}", srv.handleInternalGetTenant)
    })

    // Provider API — authenticated, rate limited
    r.Route("/api/v1", func(r chi.Router) {
        r.Use(auth.Middleware)
        r.Use(rl.Middleware)

        r.Get("/account", srv.handleGetAccount)
        r.Patch("/account", srv.handleUpdateAccount)

        r.Get("/api-keys", srv.handleListAPIKeys)
        r.Post("/api-keys", srv.handleCreateAPIKey)
        r.Delete("/api-keys/{id}", srv.handleDeleteAPIKey)

        r.Get("/tenants", srv.handleListTenants)
        r.Post("/tenants", srv.handleCreateTenant)
        r.Get("/tenants/{id}", srv.handleGetTenant)
        // ... 40+ more endpoints

        r.Route("/admin", func(r chi.Router) {
            r.Use(srv.adminGuard)
            r.Get("/metrics", srv.handleAdminMetrics)
            r.Get("/config", srv.handleListAdminConfig)
            r.Put("/config/{key}", srv.handleSetAdminConfig)
        })
    })

    return r
}

Three things I want to highlight about this structure.

1. Middleware scoping is visual

Look at the nesting. You can see the auth boundaries:

• /healthz: no middleware beyond the global stack
• /api/v1/waitlist: IP rate limiting via r.With(), no auth
• /api/v1/internal/*: internal API key auth
• /api/v1/*: Clerk JWT or API key auth + per-key rate limiting
• /api/v1/admin/*: all of the above, plus admin role check With Gin, you'd create route groups and attach middleware to each group. The structure is similar, but Chi's r.Route() nesting makes the middleware inheritance obvious just by reading the indentation. When a new developer (or new team member) opens this file.

2. r.With() for one-off middleware

The waitlist endpoint is public but rate-limited. Instead of creating a whole route group for one endpoint, Chi lets you do:

r.With(rl.IPMiddleware(10)).Post("/api/v1/waitlist", srv.handleJoinWaitlist)

r.With() applies middleware to just that route. No new group, no nesting ceremony. This is surprisingly useful when you have a few endpoints that need special treatment.

3. The Deps pattern

This isn't Chi-specific, but Chi makes it natural. Because handlers are methods on a Server struct, and the router is built by a function that takes a Deps struct, wiring dependencies is explicit:

type Deps struct {
    Store         store.Store
    Redis         *redis.Client
    Logger        *slog.Logger
    JWKSURL       string
    EventBus      *events.EventBus
    Queue         *queue.Queue
    Orchestrator  orchestrator.Orchestrator
    // ... 
}

No globals. No init() magic. Every dependency is injected through Deps, and the Server struct holds what handlers need. This makes testing straightforward; you mock the store.Store interface and pass it in.

The Dual Auth Middleware

Here's where Chi's net/http compatibility paid off the most. My API serves two types of clients:

1. The frontend dashboard: a Next.js frontend that sends Clerk JWTs
2. Programmatic consumers: B2B SaaS providers using API keys Both hit the same endpoints. The middleware auto-detects which auth mode is in play:

func (a *Auth) Middleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        token := extractBearerToken(r)

        var provider *store.Provider
        var err error

        if strings.HasPrefix(token, "sk_") {
            provider, err = a.authenticateAPIKey(r.Context(), token)
        } else {
            provider, err = a.authenticateJWT(r.Context(), token)
        }

        if provider == nil || err != nil {
            api.ErrUnauthorized(w, r, "invalid or expired credentials")
            return
        }

        ctx := context.WithValue(r.Context(), providerContextKey{}, provider)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

This is a standard func(http.Handler) http.Handler. I didn't need a Chi-specific middleware type, a Gin adapter, or anything framework-aware. The JWKS caching, bcrypt comparison with prefix lookup, and auth result caching all live in the Auth struct; the framework never enters the picture.

Any handler downstream calls middleware.GetProvider(r.Context()) and gets the authenticated provider, regardless of whether they authenticated with a JWT or an API key.

What I Miss From Gin

I'll be honest about the tradeoffs.

Binding and validation. Gin has c.ShouldBindJSON(&body) which validates struct tags automatically. With Chi, I decode JSON manually:

var body struct {
    Name     string `json:"name"`
    DbEngine string `json:"db_engine"`
}
if err := json.NewDecoder(r.Body).Decode(&body); err != nil {
    pkgapi.ErrBadRequest(w, r, "invalid request body")
    return
}
if body.Name == "" {
    pkgapi.ErrBadRequest(w, r, "name is required")
    return
}

More boilerplate? Yes. But I know exactly what's happening. There's no magic struct tag that silently returns a 400 with a format I don't control. My error responses are consistent because I control them.

Less handholding for beginners. Gin has more examples, more Stack Overflow answers, more tutorials. Chi's documentation is good but minimal. If you're building your first Go API, Gin is a smoother onramp.

No built-in response helpers. Gin has c.JSON(200, data). With Chi, I wrote a small pkg/api package:

func JSON(w http.ResponseWriter, r *http.Request, status int, data interface{}) {
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(status)
    json.NewEncoder(w).Encode(envelope{Data: data, Meta: meta(r)})
}

Ten lines of code I had to write once. Not a big deal, but it's not free either.

When I'd Choose Gin Instead

If I were building a quick CRUD API with 10 endpoints, no complex middleware layering, and I wanted to ship fast, then it's Gin. Its batteries-included approach is a real productivity boost for smaller projects.

If I were onboarding a team of junior Go developers, then of course, Gin. More resources, more patterns to copy, less "figure it out yourself."

When Chi Wins

If your API has multiple authentication modes, if your middleware stack has real layering (public vs authenticated vs admin vs internal), if you want your handlers to be portable http.HandlerFunc functions, if you care about net/http ecosystem compatibility, then it's Chi.

For me, the deciding factor was simple: Chi doesn't own my code. My handlers, my middleware, my response format, they're all standard Go. Chi is just the router. If Chi disappeared tomorrow, I'd swap in http.ServeMux from Go 1.22+ and change maybe 20 lines.

That's the kind of dependency I'm comfortable with.

What's your go-to Go router? Have you made a framework switch mid-project that you didn't regret?

---

I'm Jonathan, I build infrastructure tools with Go and Kubernetes. Currently building Staxa, a multi-tenant deployment platform. Follow me for more Go and DevOps content.