Go's net/http: Building Production HTTP Servers Without a Framework

Go’s net/http is frequently underrated. The ecosystem has frameworks — Chi, Gin, Echo, Fiber — and they’re fine choices, but the standard library gets you remarkably far without additional dependencies. After building several production APIs that stayed on raw net/http, here’s the honest assessment of what you can and can’t do without a framework, and the patterns that make it work.

What net/http Gives You

Out of the box:

HTTP/1.1 and HTTP/2 (TLS required for H2, handled automatically)
Request multiplexing via ServeMux
Goroutine per connection (managed internally)
Timeout configuration at the server level
TLS via crypto/tls

What it notably lacks:

Path parameters (/users/{id})
Named routes
Route grouping with shared middleware
Request body size limiting (requires manual wrapping)

The path parameter gap is the main reason teams reach for a router library. More on how to handle it below.

The Baseline Server

A production-ready server with timeouts:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
srv := &http.Server{
    Addr:    ":8080",
    Handler: mux,

    // Always set these — defaults are zero (no timeout)
    ReadTimeout:       5 * time.Second,   // time to read entire request
    WriteTimeout:      10 * time.Second,  // time to write entire response
    IdleTimeout:       120 * time.Second, // keep-alive connection idle time
    ReadHeaderTimeout: 2 * time.Second,   // time to read request headers
    MaxHeaderBytes:    1 << 20,           // 1MB max headers
}

Never run a production server without timeouts. A client that opens a connection and never sends headers will hold the goroutine forever with zero timeouts. ReadHeaderTimeout prevents this. WriteTimeout prevents slow-read clients from holding the goroutine during response streaming.

IdleTimeout controls how long HTTP/1.1 keep-alive connections stay open when idle. Too long and you accumulate file descriptors; too short and clients pay more TCP handshake overhead. 60–120 seconds is typical.

Middleware Chain

The standard middleware pattern: a function that takes an http.Handler and returns an http.Handler.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
type Middleware func(http.Handler) http.Handler

func Chain(h http.Handler, middlewares ...Middleware) http.Handler {
    for i := len(middlewares) - 1; i >= 0; i-- {
        h = middlewares[i](h)
    }
    return h
}

// Usage
mux.Handle("/api/trades", Chain(
    tradesHandler,
    requireAuth,
    requestLogger,
    requestID,
))

Standard middleware you’ll write once and reuse:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// Request ID — attach a unique ID to every request for correlation
func requestID(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        id := r.Header.Get("X-Request-ID")
        if id == "" {
            id = uuid.New().String()
        }
        ctx := context.WithValue(r.Context(), ctxKeyRequestID, id)
        w.Header().Set("X-Request-ID", id)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

// Request logger — structured log on every request completion
func requestLogger(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        rw := &responseWriter{ResponseWriter: w, status: 200}
        next.ServeHTTP(rw, r)
        slog.Info("request",
            "method",   r.Method,
            "path",     r.URL.Path,
            "status",   rw.status,
            "duration", time.Since(start),
            "request_id", requestIDFromCtx(r.Context()),
        )
    })
}

// responseWriter wraps to capture status code
type responseWriter struct {
    http.ResponseWriter
    status int
}
func (rw *responseWriter) WriteHeader(code int) {
    rw.status = code
    rw.ResponseWriter.WriteHeader(code)
}

Path Parameters Without a Framework

http.ServeMux in Go 1.22+ supports path parameters and method routing natively:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
// Go 1.22+ — method and path parameters in stdlib
mux.HandleFunc("GET /trades/{id}", func(w http.ResponseWriter, r *http.Request) {
    id := r.PathValue("id")  // "id" from the pattern
    // ...
})

mux.HandleFunc("GET /instruments/{sym}/history", func(w http.ResponseWriter, r *http.Request) {
    sym := r.PathValue("sym")
    // ...
})

Before 1.22, the standard approach was to use strings.TrimPrefix and manual parsing for simple cases, or add a lightweight router (chi is 600 lines of code with no dependencies, httprouter is similarly minimal). For Go 1.22+, the stdlib mux handles most routing needs.

Graceful Shutdown

A server that drops in-flight requests when the process exits is a production bug. Graceful shutdown waits for in-flight requests to complete:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
func main() {
    srv := &http.Server{Addr: ":8080", Handler: buildMux()}

    // Start server in background
    go func() {
        if err := srv.ListenAndServe(); err != nil && !errors.Is(err, http.ErrServerClosed) {
            log.Fatal(err)
        }
    }()

    // Wait for OS signal
    quit := make(chan os.Signal, 1)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
    <-quit

    slog.Info("shutting down server")

    // Give in-flight requests up to 30s to complete
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    if err := srv.Shutdown(ctx); err != nil {
        slog.Error("shutdown error", "err", err)
    }
    slog.Info("server stopped")
}

srv.Shutdown(ctx) stops accepting new connections and waits for active handlers to return. If the context deadline is exceeded before all handlers finish, it returns an error (handlers are still forcibly closed by the context cancellation). 30 seconds is a reasonable timeout for most APIs; adjust for handlers that may do long work.

Observability: What to Instrument

Minimum viable instrumentation for an HTTP server:

Metric	Type	Labels
`http_requests_total`	Counter	method, path (template), status_code
`http_request_duration_seconds`	Histogram	method, path (template), status_code
`http_requests_in_flight`	Gauge	—
`http_response_size_bytes`	Histogram	method, path

The key: use the route template (/trades/{id}) as the label, not the actual path (/trades/12345). Using the actual path creates unbounded label cardinality — a separate time series per trade ID is a metrics cardinality explosion.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
func metricsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        rw    := &responseWriter{ResponseWriter: w, status: 200}

        inFlight.Inc()
        defer inFlight.Dec()

        next.ServeHTTP(rw, r)

        pattern := r.Pattern // Go 1.22: matched route pattern
        duration := time.Since(start).Seconds()

        requestsTotal.WithLabelValues(r.Method, pattern, strconv.Itoa(rw.status)).Inc()
        requestDuration.WithLabelValues(r.Method, pattern).Observe(duration)
    })
}

When to Add a Framework

After years of this pattern, I add a framework when:

The routing logic is genuinely complex — many path parameters, complex nesting, route groups with different middleware trees. Chi or Gorilla Mux handles this more cleanly than manual mux composition.
The team is unfamiliar with HTTP primitives — a framework provides guardrails and familiar patterns. net/http rewards understanding; it punishes wrong assumptions about streaming, buffering, and header writing.
OpenAPI / Swagger generation is needed — frameworks often have codegen tooling that reduces boilerplate.

The case against framework defaults: most frameworks add dependencies, each with their own maintenance trajectory. A service built on raw net/http has one less dependency to worry about when the next framework major version breaks backwards compatibility. For internal services with stable teams, the stdlib is the stable choice.

What net/http Gives You#

The Baseline Server#

Middleware Chain#

Path Parameters Without a Framework#

Graceful Shutdown#

Observability: What to Instrument#

When to Add a Framework#