DEV Community: Abhishek Sharma

I Needed to Send an HTTP Request Without Slowing Down My API. Goroutines Fixed That.

Abhishek Sharma — Tue, 05 May 2026 13:54:02 +0000

In Part 12, I added resilience patterns — retry, timeout, circuit breaker. My backend could now survive Redis going down.

But there was still a problem. When someone created an entry, I needed to notify an external service. A webhook: fire an HTTP POST, tell the world something happened.

I added it inline in the handler:

func CreateEntry(w http.ResponseWriter, r *http.Request) {
    // ... validate, save to DB ...
    webhook.Send(url, payload) // 🐌 blocks here
    respondJSON(w, http.StatusCreated, ...)
}

The user waited. Not for their entry to save — that was fast. They waited for my HTTP request to some external service to complete. If that service was slow, every create request was slow. If it was down, every create request failed.

The handler shouldn't care whether the webhook delivery succeeded. The entry was saved. That's the job. Everything else is secondary.

I needed fire-and-forget.

The Wrong Mental Model

My first instinct: just run it in a goroutine.

go webhook.Send(url, payload) // "fire and forget", right?

Technically works. But now I have an unbounded number of goroutines. 10,000 entries created? 10,000 goroutines, each holding an HTTP connection, all fighting over bandwidth. Goroutines are cheap but not free — and more importantly, there's no control. No backpressure. No way to say "slow down."

The correct solution is a worker pool with a channel.

The Pizza Shop Mental Model

Imagine a pizza shop:

Channel = the order counter. Tickets pile up here.
Workers = the chefs. Fixed number. Each processes one order at a time.
Handler = the cashier. Takes the order, puts it on the counter, immediately says "order received." Doesn't wait for the pizza.

The cashier's job is done in milliseconds. The chefs handle the rest in the background. If the shop gets slammed, orders queue up — but there's a limit. If the queue is full, you say "we're busy, try later" instead of spinning up infinite chefs.

The Worker Pool

type Job struct {
    Type    string
    Payload interface{}
}

var JobQueue chan Job

func StartWorkerPool(numWorkers int) {
    JobQueue = make(chan Job, 100) // buffered: 100 jobs can queue up

    for i := 1; i <= numWorkers; i++ {
        go worker(i)
    }

    slog.Info("Worker pool started", "workers", numWorkers)
}

func worker(id int) {
    for job := range JobQueue {
        processJob(job)
    }
}

Three things to understand:

Buffered channel (make(chan Job, 100)): The queue can hold 100 jobs without blocking. When the handler sends a job, it returns immediately if there's space. If the queue is full, the select in AddJob drops it with a warning rather than blocking the handler.

for job := range JobQueue: This blocks until a job arrives, processes it, then loops back and blocks again. No busy-waiting. No polling. The goroutine sleeps until there's work. When JobQueue is closed, the loop exits cleanly — that's how graceful shutdown works.

Fixed goroutine count: Three workers (configurable). Not one goroutine per request. The pool handles any volume without spinning up new goroutines.

func AddJob(jobType string, payload interface{}) {
    select {
    case JobQueue <- Job{Type: jobType, Payload: payload}:
        // Added successfully
    default:
        slog.Warn("Job queue full, dropping job", "type", jobType)
    }
}

Non-blocking send with select. If the queue is full, log a warning and move on. The API response is never delayed.

The Handler Change

Before:

// Handler blocks waiting for webhook
webhook.Send(url, payload)
respondJSON(w, http.StatusCreated, ...)

After:

// Handler returns immediately, worker delivers webhook in background
worker.AddJob("entry_created", map[string]interface{}{
    "event":     "entry_created",
    "entry_id":  id,
    "user_id":   userID,
    "text":      req.Text,
    "mood":      req.Mood,
    "category":  req.Category,
    "timestamp": time.Now().UTC(),
})
respondJSON(w, http.StatusCreated, ...)

AddJob returns in nanoseconds. The user gets their 201 immediately. The worker picks up the job and delivers the webhook in the background.

The Webhook Delivery

The webhook sender itself is simple:

func Send(url string, payload interface{}) error {
    data, err := json.Marshal(payload)
    if err != nil {
        return fmt.Errorf("marshal failed: %w", err)
    }

    resp, err := http.Post(url, "application/json", bytes.NewReader(data))
    if err != nil {
        return fmt.Errorf("http post failed: %w", err)
    }
    defer resp.Body.Close()

    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        return fmt.Errorf("webhook returned non-2xx: %d", resp.StatusCode)
    }
    return nil
}

But a plain HTTP call in the background isn't resilient. The external service might be down, or slow, or return a 500. So the worker wraps delivery with retry + circuit breaker — the patterns from Post 12:

func processJob(job Job) {
    switch job.Type {
    case "entry_created", "entry_deleted":
        err := WebhookBreaker.Execute(func() error {
            return retry.Do(3, 500*time.Millisecond, func() error {
                return sender.Send(webhookURL, job.Payload)
            })
        })
        if err != nil {
            slog.Error("Webhook delivery failed", "error", err)
        }
    }
}

Three layers:

Circuit breaker: if the webhook service has 5 consecutive failures, stop trying for 30 seconds. Don't waste goroutine time on a dead service.
Retry with backoff: attempt delivery up to 3 times, waiting 500ms → 1s → 2s between attempts.
Log and continue: if all attempts fail, log it and move on. The job failing doesn't crash the worker or affect the API.

Note job.Payload — not job. The external service gets clean data:

{
  "event": "entry_created",
  "entry_id": 42,
  "user_id": 3,
  "text": "productive day",
  "mood": 8,
  "category": "work",
  "timestamp": "2026-04-17T13:37:00Z"
}

Not internal Go struct fields with type names and Go-specific formatting. Just the data the receiver actually needs.

The Tricky Part: Graceful Shutdown

Worker pools introduce a subtle problem. When the server gets a shutdown signal (Ctrl+C, SIGTERM), what happens to jobs that are queued but not yet processed?

Without graceful shutdown: server exits, 50 queued jobs dropped, 50 webhooks never sent.

The fix:

var wg sync.WaitGroup

func worker(id int) {
    for job := range JobQueue {
        wg.Add(1)
        processJob(job)
        wg.Done()
    }
}

func StopWorkerPool() {
    close(JobQueue) // signals workers to stop accepting new jobs
    wg.Wait()       // blocks until all in-progress jobs complete
}

In main.go, the graceful shutdown sequence:

// On SIGTERM/SIGINT:
server.Shutdown(ctx) // stop accepting new HTTP requests
worker.StopWorkerPool() // drain the job queue

HTTP stops first — no new jobs get created. Then the worker pool drains — all queued jobs run to completion. Then the process exits. No jobs dropped.

Putting It Together

The complete flow for POST /entries:

1. Handler receives request (milliseconds)
2. Validates input, saves to Postgres
3. Calls worker.AddJob() — returns immediately
4. Handler sends 201 to client — user is done waiting

[background, asynchronously]
5. Worker picks up job from channel
6. Circuit breaker: is webhook service healthy?
7. retry.Do: attempt 1 → fail → wait 500ms → attempt 2 → success
8. HTTP POST to webhook.site with full entry payload
9. Worker loops back and waits for next job

The user never experiences steps 5-9. They got their response at step 4.

What I Learned

Channels are not just a communication mechanism — they're a coordination tool. A buffered channel is a queue with backpressure built in. When it fills up, you know you need more workers or fewer producers. Goroutines alone give you none of that.

for job := range channel is the cleanest worker pattern in Go. It blocks, processes, loops — and exits cleanly when the channel is closed. No select, no done channel, no context. Just range over the channel.

Fire-and-forget is not the same as "spawn a goroutine." Fire-and-forget means the caller doesn't wait for the result. A worker pool is how you implement fire-and-forget responsibly — with a fixed number of workers, a bounded queue, and graceful shutdown.

Close the channel to stop workers, use WaitGroup to wait for them. This two-step pattern — close(JobQueue) then wg.Wait() — is the canonical way to drain a worker pool in Go. Close signals "no more work." WaitGroup confirms "current work is done."

Up next: the last piece of the puzzle — dependency injection refactor, per-user rate limiting, and token refresh. Everything that ties the backend together.

My Backend Crashed Every Time Redis Went Down. Three Patterns Fixed That.

Abhishek Sharma — Wed, 29 Apr 2026 14:35:02 +0000

In Part 11, I built a metrics system to see the big picture — request counts, latencies, error rates per endpoint.

Then I looked at my main.go and realized something embarrassing. The JWT secret was hardcoded. The Redis address was a string literal. The rate limit was a magic number buried in middleware. Every config value was scattered across different files with no central source of truth.

And then Redis went down during a test, and my entire backend froze. Every request hung for 5 seconds waiting for a timeout. The server was technically running but completely useless.

Two problems. One week.

Problem 1: Config Values Everywhere

My main.go looked like this:

err = db.InitDB("./data.db")
err = redis.InitRedis("localhost:6379")

// Somewhere in a handler file:
secret := os.Getenv("JWT_SECRET")

// Somewhere in middleware:
maxRequests := 100
window := 60 * time.Second

Four files. Four different patterns for reading config. Some used os.Getenv, some were hardcoded, some had defaults and some didn't. If I wanted to change the rate limit, I had to know it lived inside ratelimit.go. If I forgot to set JWT_SECRET, the server would boot and silently produce invalid tokens.

The Fix: One Struct, One Function

type Config struct {
    Port             string
    DBPath           string
    RedisAddr        string
    JWTSecret        string
    LogLevel         string
    ShutdownTimeout  time.Duration
    RateLimitRequests int
    RateLimitWindow  time.Duration
    WorkerPoolSize   int
}

Every setting the app needs, in one place. Then a single Load() function that reads environment variables with sensible defaults:

func Load() (*Config, error) {
    cfg := &Config{}

    cfg.Port = os.Getenv("PORT")
    if cfg.Port == "" {
        cfg.Port = "8080"
    }

    host := os.Getenv("REDIS_HOST")
    port := os.Getenv("REDIS_PORT")
    if host == "" { host = "localhost" }
    if port == "" { port = "6379" }
    cfg.RedisAddr = host + ":" + port

    cfg.JWTSecret = os.Getenv("JWT_SECRET")
    if cfg.JWTSecret == "" {
        return nil, fmt.Errorf("JWT_SECRET environment variable is required")
    }

    // ... more fields with defaults ...
    return cfg, nil
}

The critical line: if JWT_SECRET is empty, Load() returns an error and the server refuses to start. Before, it would boot silently and produce tokens signed with an empty string. Now it fails fast at startup, not at runtime.

main.go becomes clean:

cfg, err := config.Load()
if err != nil {
    slog.Error("Failed to load configuration", "error", err)
    os.Exit(1)
}

err = db.InitDB(cfg.DBPath)
err = redis.InitRedis(cfg.RedisAddr)
handlers.RateLimitRequests = cfg.RateLimitRequests
handlers.RateLimitWindow = cfg.RateLimitWindow

One source of truth. Every component reads from the same struct. Want to change the rate limit? Change the RATE_LIMIT_REQUESTS env var. Don't want to set anything? Defaults kick in. Want to know every config value the app uses? Read one file.

This is the 12-Factor App pattern: configuration lives in environment variables, not in code.

Problem 2: My Backend Can't Handle Failure

With config sorted, I moved to a harder problem. My backend assumed every external service was always available. Redis up? Great. Redis down? Total freeze.

Here's what happened when Redis died:

Request 1:  user hits /entries → tries Redis cache → waits 5s timeout → fails → 5s wasted
Request 2:  another user → same thing → 5s wasted
Request 50: still hammering dead Redis → 50 goroutines stuck waiting
Server: technically running, practically dead

I needed three things: retry failed connections, time out hung requests, and stop calling dead services.

Pattern 1: Retry with Exponential Backoff

Sometimes Redis isn't dead — it's just restarting. My Docker setup starts Redis and my app simultaneously. The app tries to connect, Redis isn't ready yet, app crashes. Five seconds later Redis is fine. My app is dead.

func Do(maxAttempts int, initialDelay time.Duration, operation func() error) error {
    var lastErr error
    delay := initialDelay

    for attempt := 1; attempt <= maxAttempts; attempt++ {
        lastErr = operation()
        if lastErr == nil {
            if attempt > 1 {
                slog.Info("Operation succeeded after retry",
                    "attempt", attempt)
            }
            return nil
        }

        if attempt == maxAttempts {
            break
        }

        slog.Warn("Operation failed, retrying",
            "attempt", attempt,
            "next_delay", delay.String(),
            "error", lastErr)

        time.Sleep(delay)
        delay *= 2 // Exponential backoff
    }

    return fmt.Errorf("operation failed after %d attempts: %w", maxAttempts, lastErr)
}

The key insight is delay *= 2. Not immediate retries — that hammers a struggling service. Wait 500ms, then 1s, then 2s. Give the service time to recover.

Applied to Redis initialization:

err := retry.Do(3, 500*time.Millisecond, func() error {
    _, err := Client.Ping(context.Background()).Result()
    return err
})

Three attempts, starting at 500ms. If Redis needs 2 seconds to boot, my app survives. Before, it crashed on the first failed ping.

The function signature — operation func() error — is a higher-order function. Do() doesn't know or care what it's retrying. Redis ping, database query, HTTP call. Write retry logic once, use it for anything.

Pattern 2: Request Timeout

Retries handle startup failures. But what about a request that hangs during normal operation? A slow database query. A Redis call that never returns. Without a timeout, that goroutine blocks forever — a goroutine leak. Enough leaked goroutines and the server runs out of memory.

func TimeoutMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        ctx, cancel := context.WithTimeout(r.Context(), RequestTimeout)
        defer cancel()

        r = r.WithContext(ctx)

        done := make(chan struct{})

        go func() {
            next(w, r)
            close(done)
        }()

        select {
        case <-done:
            // Handler finished normally
            return
        case <-ctx.Done():
            // Timeout expired
            slog.Warn("Request timeout",
                "method", r.Method,
                "path", r.URL.Path,
                "timeout", RequestTimeout.String())
            http.Error(w, "Request timed out", http.StatusGatewayTimeout)
            return
        }
    }
}

context.WithTimeout creates a context that automatically cancels after a deadline. The handler runs in a goroutine. A select statement waits for whichever happens first: the handler finishes, or the timeout fires.

If the timeout wins, the client gets a 504 immediately instead of waiting forever. The handler goroutine keeps running in the background (you can't forcefully kill goroutines in Go), but because we passed the timeout context to r.WithContext(ctx), any downstream db.QueryContext(ctx, ...) or redis.Client.Get(ctx, key) will also abort when the context cancels.

The select pattern is one of those Go concurrency primitives that seems simple but solves a hard problem: "wait for A or B, whichever comes first."

Pattern 3: Circuit Breaker

Retries handle temporary failures. Timeouts prevent hung requests. But neither solves this: Redis is down. Not slow, not restarting. Down. Every request still tries Redis, waits for the timeout, and fails. You're burning 5 seconds per request on a service you already know is dead.

The circuit breaker is named after the electrical MCB in your home's fuse box. Overload trips the breaker, cuts the circuit, protects the wiring. Same idea:

type CircuitBreaker struct {
    state           string        // "closed", "open", "half-open"
    failureCount    int
    lastFailureTime time.Time
    threshold       int           // failures before tripping
    cooldown        time.Duration // how long to stay open
    mu              sync.Mutex
}

Three states:

Closed (normal) — requests flow through. Failures are counted. Hit the threshold? Trip to open.

Open (tripped) — all requests rejected immediately without calling the service. No 5-second waits. No goroutine leaks. After a cooldown period, move to half-open.

Half-open (testing) — allow one request through. If it succeeds, the service recovered — back to closed. If it fails, back to open for another cooldown.

func (cb *CircuitBreaker) Execute(operation func() error) error {
    cb.mu.Lock()
    defer cb.mu.Unlock()

    switch cb.state {
    case "closed":
        err := operation()
        if err != nil {
            cb.failureCount++
            cb.lastFailureTime = time.Now()
            if cb.failureCount >= cb.threshold {
                cb.state = "open"
            }
            return err
        }
        cb.failureCount = 0
        return nil

    case "open":
        if time.Since(cb.lastFailureTime) > cb.cooldown {
            cb.state = "half-open"
            err := operation()
            if err != nil {
                cb.state = "open"
                cb.lastFailureTime = time.Now()
                return err
            }
            cb.state = "closed"
            cb.failureCount = 0
            return nil
        }
        return fmt.Errorf("circuit breaker is open")

    case "half-open":
        // ... same test-and-recover logic
    }
    return nil
}

Applied to every Redis operation:

var RedisBreaker = circuitbreaker.NewCircuitBreaker(5, 30*time.Second)

func Get(key string) (string, bool) {
    var result string
    err := RedisBreaker.Execute(func() error {
        var err error
        result, err = redis.Client.Get(context.Background(), key).Result()
        return err
    })
    if err != nil {
        return "", false
    }
    return result, true
}

Five failures and the breaker trips. For the next 30 seconds, every Redis call returns instantly with an error instead of waiting for a timeout. After 30 seconds, one test request checks if Redis is back. If yes, normal operation resumes. If no, another 30-second cooldown.

Without circuit breaker (Redis down):

Request 1-100: each waits 5s timeout → 500s total wasted

With circuit breaker (Redis down):

Request 1-5:   each waits 5s timeout → 25s wasted, breaker trips
Request 6-100: instant reject <1ms each → ~0s wasted

The server stays responsive. Users get fast errors instead of frozen pages. And when Redis recovers, traffic flows again automatically.

How They Work Together

The three patterns complement each other:

Retry handles transient failures — a service that's temporarily unavailable during startup or a brief blip. Try again with backoff.

Timeout prevents indefinite waits — if a request can't complete in 10 seconds, kill it. Don't let one slow service freeze the whole server.

Circuit breaker prevents repeated failures — if a service is genuinely down, stop calling it entirely. Fail fast, protect the server, auto-recover when the service comes back.

What I Learned

Config should be boring. One struct, one loader, fail at startup not runtime. The moment I centralized config, I stopped having "it works on my machine" bugs. Every deployment reads from the same env vars.

Fail fast beats fail slow. A 504 in 10 seconds is bad. A 504 in 0ms is useful — the client can retry, show a cached version, or degrade gracefully. The circuit breaker turns slow failures into fast failures.

Higher-order functions unlock reusable patterns. retry.Do(attempts, delay, func() error { ... }) and breaker.Execute(func() error { ... }) both take functions as arguments. Write the pattern once, wrap any operation. This is how Go avoids needing generics for most resilience code.

select is the most powerful statement in Go. "Wait for A or B, whichever comes first" — that's the timeout middleware in one sentence. Channels + select is how Go makes concurrency manageable.

Up next: I needed my backend to notify external services when things happened — new entries, deleted data. But HTTP calls inside request handlers block the response. So I built a webhook system with fire-and-forget delivery, backed by a worker pool using goroutines and channels. Concurrency in Go, for real this time.

I Had No Idea Which Endpoint Was Slowest. So I Built My Own Metrics.

Abhishek Sharma — Tue, 28 Apr 2026 13:21:42 +0000

In Part 10, I added structured logging and request IDs. I could now trace a single request through my entire backend — every log line tagged, searchable, debuggable in seconds.

But I still couldn't answer basic questions:

How many requests did /entries handle today?
What's the average response time for /login?
Which endpoint is the slowest?
Are errors increasing?

I had detailed logs for individual requests but zero visibility into the system as a whole. That's like having a microscope but no dashboard. I needed metrics.

What Metrics Actually Are

Logs tell you what happened to one request. Metrics tell you what's happening across all requests.

Three types:

Counters — only go up. Total requests, total errors. "We've served 50,000 requests since boot."
Gauges — go up and down. In-flight requests right now. "There are 3 requests being processed."
Latency stats — how fast. Average, min, max response time. "/entries averages 45ms but spiked to 2000ms."

I could have used Prometheus. But I wanted to understand what a metrics system actually does before adding a library. So I built one from scratch.

The Metrics Struct

type Metrics struct {
    mu sync.RWMutex

    // Counters (only increase)
    requestCount map[string]int64
    errorCount   map[string]int64

    // Gauges (go up and down)
    inFlight map[string]int64

    // Latency stats
    totalLatency map[string]float64
    minLatency   map[string]float64
    maxLatency   map[string]float64
}

Every field is a map[string] keyed by endpoint path. /entries, /login, /health — each gets its own counters.

sync.RWMutex is critical. Multiple goroutines (concurrent requests) read and write these maps simultaneously. Without the mutex, you get a race condition — two goroutines incrementing requestCount["/entries"] at the same time, one write gets lost.

RWMutex specifically lets multiple readers run concurrently (reading metrics is frequent and safe) but locks exclusively for writes. A regular Mutex would block all readers while any single request updates its counter.

Two Functions: Start and Complete

func (m *Metrics) RequestStarted(path string) {
    m.mu.Lock()
    m.inFlight[path]++
    defer m.mu.Unlock()
}

func (m *Metrics) RequestCompleted(path string, duration float64, statusCode int) {
    m.mu.Lock()
    defer m.mu.Unlock()

    m.inFlight[path]--
    m.requestCount[path]++

    if statusCode >= 400 {
        m.errorCount[path]++
    }

    m.totalLatency[path] += duration

    if _, exists := m.minLatency[path]; !exists {
        m.minLatency[path] = math.MaxFloat64
    }
    if duration < m.minLatency[path] {
        m.minLatency[path] = duration
    }
    if duration > m.maxLatency[path] {
        m.maxLatency[path] = duration
    }
}

RequestStarted bumps the in-flight gauge. RequestCompleted decrements it, increments the counter, tracks errors (any status >= 400), and updates latency stats. The min latency trick: initialize to math.MaxFloat64 so the first real duration is always smaller.

The Problem: How Do You Capture the Status Code?

Here's something I didn't expect. Go's http.ResponseWriter doesn't let you read the status code after it's been written. Once a handler calls w.WriteHeader(200), that information is gone — it's sent to the client and the ResponseWriter doesn't store it.

So how do you know if a request returned 200 or 500?

You wrap it:

type responseWriter struct {
    http.ResponseWriter
    statusCode int
}

func (rw *responseWriter) WriteHeader(statusCode int) {
    rw.statusCode = statusCode          // Save it
    rw.ResponseWriter.WriteHeader(statusCode) // Pass it through
}

This is an embedding + interception pattern. The custom responseWriter embeds the real one. Every method works normally — except WriteHeader, which we override to capture the status code before passing it through.

The handler doesn't know it's writing to a wrapper. It calls w.WriteHeader(500) like normal. But now we have the status code stored in rw.statusCode.

The Metrics Middleware

var AppMetrics = metrics.NewMetrics()

func MetricsMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        path := r.URL.Path
        AppMetrics.RequestStarted(path)
        start := time.Now()

        wrapped := &responseWriter{
            ResponseWriter: w,
            statusCode:     200, // Default if WriteHeader not called
        }
        next(wrapped, r)

        duration := time.Since(start).Milliseconds()
        AppMetrics.RequestCompleted(path, float64(duration), wrapped.statusCode)
    })
}

Before the handler runs: mark the request as in-flight, start the clock.

After the handler runs: stop the clock, record the duration and status code.

Default statusCode: 200 handles the case where a handler writes a body without explicitly calling WriteHeader — Go's http package implicitly sends 200 in that case.

The /metrics Endpoint

func GetMetrics(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodGet {
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
        return
    }

    snapshot := AppMetrics.GetSnapshot()
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(snapshot)
}

GetSnapshot() takes a read lock, loops through all tracked endpoints, and builds a response:

{
  "/entries": {
    "total_requests": 1247,
    "errors": 23,
    "in_flight": 2,
    "avg_latency_ms": 45.3,
    "min_latency_ms": 8,
    "max_latency_ms": 2100
  },
  "/login": {
    "total_requests": 89,
    "errors": 12,
    "in_flight": 0,
    "avg_latency_ms": 120.5,
    "min_latency_ms": 95,
    "max_latency_ms": 340
  }
}

One GET request and I can see: /entries has handled 1,247 requests with a 1.8% error rate, averaging 45ms but occasionally spiking to 2.1 seconds. /login is slower on average (bcrypt hashing isn't cheap) but consistent. Two requests are being processed right now.

The Middleware Chain

MetricsMiddleware wraps every route, sitting between RequestID and RateLimit:

http.HandleFunc("/entries", handlers.RequestIDMiddleware(
    handlers.MetricsMiddleware(handlers.RateLimitMiddleware(
        handlers.LoggingMiddleware(
            handlers.AuthMiddleware(entryHandler))))))

The order: RequestID (outermost) assigns the ID, MetricsMiddleware starts the clock, RateLimit checks if the request is allowed, Logging records the request, Auth verifies the token, then the handler runs. When the handler returns, the stack unwinds — MetricsMiddleware stops the clock and records the result.

Five middleware deep. Each one does exactly one thing. The handler doesn't know any of them exist.

Why Not Just Use Prometheus?

I will, eventually. But building it from scratch taught me things the Prometheus docs don't:

Why you need a mutex — not obvious until two goroutines corrupt your counter
The ResponseWriter wrapper pattern — you can't observe what you can't intercept, and Go's interface doesn't expose the status code
The difference between counters and gauges — sounds trivial until you need to track in-flight requests (which go down, so a counter won't work)
How a snapshot works — read lock, copy the maps, release, encode. Don't hold the lock while serializing JSON

The jump from "hand-built metrics" to Prometheus is just replacing my Metrics struct with prometheus.Counter and prometheus.Histogram. The middleware pattern stays identical.

What I Learned

You can't improve what you can't measure. Logs tell you about failures. Metrics tell you about trends. "Error rate went from 1% to 5% over the last hour" is something logs alone will never show you.

sync.RWMutex exists for a reason. A regular Mutex locks everyone out. RWMutex lets concurrent readers through. When your metrics endpoint is being polled every 10 seconds while hundreds of requests update counters, the distinction matters.

The ResponseWriter wrapper is a pattern you'll use everywhere. Capturing status codes, response sizes, headers — Go's http.ResponseWriter is intentionally minimal. Wrapping it with embedding is how the ecosystem extends it.

Start with what you understand, replace with tools later. I'll switch to Prometheus when I need histograms, percentiles, and Grafana dashboards. But I'll know exactly what those tools are doing under the hood because I built the primitive version first.

Up next: my backend had hardcoded config values scattered across main.go. JWT secrets, Redis hosts, database credentials — all inline. Then I started adding resilience patterns: retry with exponential backoff, request timeouts, and a circuit breaker for Redis. The week my backend learned to survive failures.

Every Request Looked the Same in My Logs. Then I Added One Line.

Abhishek Sharma — Sun, 26 Apr 2026 14:11:32 +0000

In Part 9, I Dockerized my backend and added database migrations. One command (docker compose up) now spins up Go + Postgres + Redis.

Then I hit a bug. I sent a POST to /entries and got a 500 back. No idea why.

I opened the logs:

2026/02/01 10:15:23 POST /entries - Request received
2026/02/01 10:15:23 Creating entry for user ID: 3
2026/02/01 10:15:23 POST /entries - Request received
2026/02/01 10:15:23 Creating entry for user ID: 7
2026/02/01 10:15:23 Failed to extract user_id from context
2026/02/01 10:15:23 Entry created successfully with ID: 42

Five lines. Three users. Which line belongs to which request? I had no idea. The logs were flat strings — timestamps and messages, nothing else. When two requests hit at the same millisecond, the lines interleaved and became useless.

I couldn't debug my own backend.

Step 1: Replace Every log.Printf in the Codebase

Go ships a structured logging package in the standard library: log/slog. No external dependencies. I created a logger package:

package logger

import (
    "log/slog"
    "os"
)

var Log *slog.Logger

func InitLogger() {
    handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
        Level: slog.LevelDebug,
    })
    Log = slog.New(handler)
    slog.SetDefault(Log)
}

Then I went through every file and replaced log.Printf with slog.Info, slog.Error, slog.Debug.

Before:

log.Printf("Entry created successfully with ID: %d", id)

After:

slog.Info("Entry created", "entry_id", id, "user_id", userID)

The difference isn't cosmetic. Here's what the output looks like:

Before (flat string):

2026/02/01 10:15:23 Entry created successfully with ID: 42

After (structured JSON):

{"time":"2026-02-01T10:15:23Z","level":"INFO","msg":"Entry created","entry_id":42,"user_id":3}

Every field is a key-value pair. You can search for user_id:3 to find all logs for user 3. You can filter by level:ERROR to find only failures. You can pipe everything into Datadog, ELK, or just jq on the command line:

cat logs.json | jq 'select(.user_id == 3)'

Try doing that with log.Printf("User %d created entry %d", userID, entryID). You'd need regex. For every query. Forever.

The Logging Middleware Upgrade

My logging middleware was the worst offender. Before:

func LoggingMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        current_time := time.Now().Format("2006-01-02 15:04:05")
        log.Printf("%s %s %s", current_time, r.Method, r.URL.Path)
        next(w, r)
    }
}

No duration. No way to know how long a request took. After:

func LoggingMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        next(w, r)
        duration := time.Since(start)

        slog.Info("Request",
            "method", r.Method,
            "path", r.URL.Path,
            "duration_ms", duration.Milliseconds(),
        )
    }
}

Now every request automatically logs how long it took. If a request takes 2000ms instead of 50ms, I see it instantly. Before, I would never have known.

Step 2: The Problem That Structured Logging Didn't Solve

The logs were clean now. Structured. Searchable. But go back to the original problem:

{"time":"...","level":"INFO","msg":"Request received","method":"POST","path":"/entries"}
{"time":"...","level":"DEBUG","msg":"Creating entry","user_id":3}
{"time":"...","level":"INFO","msg":"Request received","method":"POST","path":"/entries"}
{"time":"...","level":"DEBUG","msg":"Creating entry","user_id":7}
{"time":"...","level":"ERROR","msg":"Failed to extract user_id from context"}
{"time":"...","level":"INFO","msg":"Entry created","entry_id":42,"user_id":3}

Which request failed? User 3's or user 7's? The error line has no user ID — the extraction failed, so there's nothing to log. And even if it did, how do you correlate "Request received" with "Entry created" when 10 requests are running concurrently?

You need a thread that ties every log line from the same request together. That thread is a request ID.

Request IDs: One String That Changes Everything

The idea is simple: generate a unique ID when a request arrives, attach it to every log line for that request, and return it in the response header.

func RequestIDMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        requestID := GenerateRequestID()
        ctx := context.WithValue(r.Context(), "request_id", requestID)
        next(w, r.WithContext(ctx))
    }
}

func GenerateRequestID() string {
    b := make([]byte, 8)
    _, err := rand.Read(b)
    if err != nil {
        panic("failed to generate request ID: " + err.Error())
    }
    return hex.EncodeToString(b)
}

crypto/rand generates 8 random bytes. hex.EncodeToString turns them into a 16-character hex string like a3f8b2c1e9d04567. Unique enough for request tracing. Stored in the request context so every handler downstream can access it.

The Glue: Logger With Request ID

The key function that ties it all together:

func GetLoggerWithRequestID(r *http.Request) *slog.Logger {
    value := r.Context().Value("request_id")
    requestID, ok := value.(string)
    if !ok {
        requestID = ""
    }
    return slog.Default().With("request_id", requestID)
}

slog.Default().With("request_id", requestID) creates a new logger where every log line automatically includes the request ID. You don't pass it manually. You call GetLoggerWithRequestID(r) once and every .Info(), .Error(), .Debug() on that logger includes it.

The logging middleware now uses this:

func LoggingMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        next(w, r)
        duration := time.Since(start)

        logger := GetLoggerWithRequestID(r)
        logger.Info("Request",
            "method", r.Method,
            "path", r.URL.Path,
            "duration_ms", duration.Milliseconds(),
        )
    }
}

The Same Logs, Now Debuggable

{"time":"...","level":"INFO","msg":"Request received","method":"POST","path":"/entries","request_id":"a3f8b2c1"}
{"time":"...","level":"DEBUG","msg":"Creating entry","user_id":3,"request_id":"a3f8b2c1"}
{"time":"...","level":"INFO","msg":"Request received","method":"POST","path":"/entries","request_id":"d7e9f0a2"}
{"time":"...","level":"DEBUG","msg":"Creating entry","user_id":7,"request_id":"d7e9f0a2"}
{"time":"...","level":"ERROR","msg":"Failed to extract user_id","request_id":"c4b5e6f8"}
{"time":"...","level":"INFO","msg":"Entry created","entry_id":42,"user_id":3,"request_id":"a3f8b2c1"}

Now I can see:

a3f8b2c1 = User 3's request. Succeeded.
d7e9f0a2 = User 7's request. Log lines stop after "Creating entry" — something failed silently.
c4b5e6f8 = A third request entirely. The one that couldn't extract a user ID.

One jq command pulls out every line for a single request:

cat logs.json | jq 'select(.request_id == "c4b5e6f8")'

The bug that took 30 minutes to find with flat logs now takes 10 seconds.

The Middleware Chain

Request ID middleware wraps everything else — it's the outermost layer:

http.HandleFunc("/entries", handlers.RequestIDMiddleware(
    handlers.RateLimitMiddleware(handlers.LoggingMiddleware(
        handlers.AuthMiddleware(entryHandler)))))

The order matters: RequestID runs first, so the ID exists in context before the logging middleware tries to read it. If you put logging outside request ID, the first log line would have no ID.

What I Learned

log.Printf is a dead end. The moment you have more than one concurrent request, flat strings become useless. slog is in the standard library. There's no reason to use anything else for most Go backends.

Structured logging is about searchability, not readability. JSON logs look ugly in a terminal. They look beautiful in a log aggregator. You're not reading logs for fun — you're filtering them during an outage at 2 AM.

Request IDs cost almost nothing and save hours. 16 bytes of randomness per request. Stored in context. Attached to every log line. The debugging ROI is absurd.

slog.With() is the secret weapon. Instead of manually passing the request ID to every log call, slog.Default().With("request_id", id) creates a child logger that includes it automatically. One call per request, not one per log line.

Up next: I can see individual requests now, but I still can't see the big picture. How many requests per minute? What's the average response time? Which endpoints are slowest? Time to build a metrics endpoint.

My Database Disappeared Every Time I Restarted Docker. Migrations Fixed That.

Abhishek Sharma — Sat, 25 Apr 2026 17:51:53 +0000

In Part 8, I ripped out SQLite and switched to Postgres. The database was real now — but it still only ran on my laptop.

Three terminal tabs. One for go run, one for Redis, one for Postgres. If I closed any of them, the whole thing fell over.

It was time to Dockerize.

The First Dockerfile: 800MB of Regret

My first attempt was a single-stage Dockerfile. Copy everything, build, run:

FROM golang:1.25-alpine
WORKDIR /app
COPY . .
RUN go build -o server ./cmd/server
CMD ["/app/server"]

It worked. The image was 800MB. That's bigger than most operating systems. I was shipping the entire Go compiler, my source code, and every dependency just to run a 15MB binary.

Multi-Stage Builds: The Aha Moment

The fix is a pattern called multi-stage builds. Two FROM statements in one Dockerfile:

# STAGE 1: Build (heavy — has Go compiler)
FROM golang:1.25-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o server ./cmd/server

# STAGE 2: Run (tiny — just Alpine + binary)
FROM alpine:latest
RUN apk add --no-cache ca-certificates
WORKDIR /app
COPY --from=builder /app/server /app/server
EXPOSE 8080
CMD ["/app/server"]

Stage 1 is a construction site — Go compiler, 300MB of build tools, your source code. It compiles your app into a single binary.

Stage 2 is the delivery box — a bare Alpine Linux image (~5MB) with just your binary copied in. The entire build stage gets thrown away.

Result: ~15MB. From 800MB to 15MB. Same binary. Same functionality. One line did the heavy lifting:

COPY --from=builder /app/server /app/server

That --from=builder is reaching back into the dead first stage and grabbing the one file that matters.

The CGO Trap

RUN CGO_ENABLED=0 GOOS=linux go build -o server ./cmd/server

CGO_ENABLED=0 tells Go: don't use any C libraries. Without it, the binary links against glibc — but Alpine uses musl. The binary compiles fine in the builder, then crashes in the runner with a cryptic error. I learned this the hard way.

This produces a static binary — completely self-contained. It doesn't need Go, doesn't need C, doesn't need anything except a Linux kernel to run.

Docker Compose: One Command to Rule Them

My backend needs three services: Go app + Postgres + Redis. Without docker-compose, starting the stack looks like:

docker network create mynet
docker run -d --name postgres --network mynet -e POSTGRES_USER=user ...
docker run -d --name redis --network mynet redis:alpine
docker build -t myapp . && docker run --network mynet -e DB_HOST=postgres ...

With docker-compose:

docker compose up

That's it. One command. Here's the full stack definition:

services:
  app:
    build: .
    restart: on-failure
    ports:
      - "8080:8080"
    environment:
      - JWT_SECRET=supersecretkey
      - REDIS_HOST=redis
      - DB_HOST=postgres
      - DB_PORT=5432
      - DB_USER=user
      - DB_PASSWORD=password
      - DB_NAME=analytics
    depends_on:
      redis:
        condition: service_started
      postgres:
        condition: service_healthy

  redis:
    image: redis:alpine
    ports:
      - "6379:6379"

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: analytics
    ports:
      - "5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d analytics"]
      interval: 5s
      timeout: 5s
      retries: 5

Three things I didn't know before writing this:

Docker Compose networking is automatic. The service name is the hostname. My Go app connects to redis and postgres — not localhost. Docker creates a virtual network and resolves service names to container IPs. No manual network setup.

depends_on isn't enough. Just because Postgres starts doesn't mean it's ready. depends_on with condition: service_healthy waits for the healthcheck to pass. Without it, my Go app would boot, try to connect, fail, and crash — 50% of the time.

restart: on-failure is a safety net. If the app crashes during the startup race (Redis isn't ready, Postgres is still initializing), Docker restarts it automatically. Crude but effective.

The Problem Nobody Mentions

I ran docker compose up. Everything worked. Tables created. API responded. I inserted some entries, tested auth — beautiful.

Then I ran docker compose down and docker compose up again.

Tables were gone. Data gone. Schema gone. Every restart was a blank slate.

My CREATE TABLE IF NOT EXISTS code ran on every boot, so the tables came back — but this was hardcoded SQL strings inside Go functions. The moment I needed to add a column, rename a field, or create a new table, I'd have to manually edit Go code and hope the IF NOT EXISTS didn't silently ignore my changes.

This is the problem database migrations solve.

Migrations: Schema as Code

Instead of SQL strings buried in Go code, I created a migrations/ folder:

internal/db/migrations/
├── 000001_create_users.up.sql
├── 000001_create_users.down.sql
├── 000002_create_entries.up.sql
├── 000002_create_entries.down.sql

Each migration is a pair: up (apply) and down (rollback).

-- 000001_create_users.up.sql
CREATE TABLE IF NOT EXISTS users (
    id SERIAL PRIMARY KEY,
    email TEXT UNIQUE NOT NULL,
    password_hash TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

-- 000001_create_users.down.sql
DROP TABLE IF EXISTS users;

Simple SQL files. Numbered. Versioned. Reviewable in a PR.

golang-migrate: The Runner

I used golang-migrate to execute these files on startup:

import (
    "github.com/golang-migrate/migrate/v4"
    _ "github.com/golang-migrate/migrate/v4/database/postgres"
    _ "github.com/golang-migrate/migrate/v4/source/file"
)

func RunMigrations(dsn string) error {
    m, err := migrate.New(
        "file://internal/db/migrations",
        dsn,
    )
    if err != nil {
        return fmt.Errorf("creating migrator: %w", err)
    }
    defer m.Close()

    if err := m.Up(); err != nil && err != migrate.ErrNoChange {
        return fmt.Errorf("running migrations: %w", err)
    }

    slog.Info("Database migrations applied")
    return nil
}

m.Up() runs every unapplied migration in order. If all migrations are already applied, it returns migrate.ErrNoChange — which we ignore. Idempotent. Safe to run on every boot.

Behind the scenes, golang-migrate creates a schema_migrations table in Postgres that tracks which version has been applied:

version | dirty
--------+------
      2 | false

Version 2 means both 000001 and 000002 have run. dirty: false means no migration failed halfway. If I add 000003_add_tags_column.up.sql tomorrow and restart — only migration 3 runs. The first two are skipped.

The DSN Gotcha

One thing that tripped me up: database/sql and golang-migrate expect different connection string formats.

// database/sql wants key=value format
dsn := fmt.Sprintf("host=%s port=%s user=%s password=%s dbname=%s sslmode=disable",
    cfg.DBHost, cfg.DBPort, cfg.DBUser, cfg.DBPassword, cfg.DBName)

// golang-migrate wants URL format
migrateDSN := fmt.Sprintf("postgres://%s:%s@%s:%s/%s?sslmode=disable",
    cfg.DBUser, cfg.DBPassword, cfg.DBHost, cfg.DBPort, cfg.DBName)

err = db.InitDB(dsn, migrateDSN)

Same credentials, different format. I spent 30 minutes debugging "invalid connection string" before I realized the migrate driver expects a URL, not key-value pairs.

The Dockerfile Update

Migrations are SQL files on disk. The runner stage needs them:

COPY --from=builder /app/server /app/server
COPY --from=builder /app/internal/db/migrations /app/internal/db/migrations

Without this line, the container boots, tries to read file://internal/db/migrations, finds nothing, and silently starts with no tables.

Before and After

Before:

Terminal 1: docker run postgres ...
Terminal 2: docker run redis ...
Terminal 3: go run cmd/server/main.go
Schema: hardcoded in Go functions
Adding a column: edit Go code, pray

After:

docker compose up
Schema: versioned SQL files
Adding a column: write a new .sql file, restart

What I Learned

Multi-stage builds are non-negotiable. Every Go project should ship a ~15MB image, not an 800MB one. The pattern is always the same: build in golang:alpine, run in alpine:latest.

Docker Compose replaces three terminal tabs with one command. Service names become hostnames. Health checks prevent race conditions. restart: on-failure handles the rest.

CREATE TABLE IF NOT EXISTS is not a migration strategy. It works until you need to change something. Real migrations are numbered SQL files, tracked by a version table, applied in order. The tooling exists. There's no excuse to skip it.

Schema should live next to code, not inside it. When your table definitions are .sql files in a migrations/ folder, they show up in diffs, get reviewed in PRs, and can be rolled back. When they're string literals inside Go functions, they're invisible.

Up next: the thing I kept running into while building all of this — I couldn't debug anything without proper logging. So I replaced log.Println with structured JSON logging, added request IDs for tracing, and built a metrics endpoint. The week my backend learned to explain itself.

I Built My Backend on SQLite. Then I Deleted It.

Abhishek Sharma — Fri, 24 Apr 2026 13:44:17 +0000

In Part 7, I taught my server how to die gracefully. It felt production-ready. Auth, rate limiting, caching, clean shutdown â€” the API was doing real work.

I said Part 8 would be "Docker + Postgres." I was wrong. Postgres alone deserved its own post, because swapping the database under a running backend taught me more in a weekend than the three weeks before it.

Then I tried to run my tests in CI.

And everything broke.

The SQLite Honeymoon

When I started this project, SQLite was the obvious choice:

import _ "modernc.org/sqlite"

DB, err = sql.Open("sqlite", "./data.db")

One file. No server. No Docker. No connection strings. Pure Go driver â€” not even CGO. It felt like cheating. I built auth, entries, pagination, rate limiting, and caching all on top of a single .db file sitting next to my binary.

For 7 posts, SQLite carried this backend beautifully.

Then I wrote this in my GitHub Actions workflow:

- name: Run tests
  run: go test ./...

And the CI logs lit up red. Concurrent test runs stepping on each other. File locks. Tests that passed locally failed in CI. Tests that passed in CI failed on the next run.

SQLite isn't broken. But it's a single-writer database pretending to be a multi-user one. The moment my test suite started running handlers in parallel, the cracks showed.

Day 23: The Choice

I had two options:

Make SQLite work â€” serialize tests, mock the DB layer, fight the concurrency model
Switch to Postgres â€” the thing I'd use in production anyway

I picked #2. Not because SQLite is bad, but because I was lying to myself. Every tutorial that says "SQLite is fine for production" forgets to mention the asterisk: unless you need concurrent writes, CI pipelines, connection pooling, or anything resembling a real deployment.

If I was going to deploy this, it was going to hit Postgres eventually. Better to feel that pain on Day 23 than on launch day.

The Migration That Looked Simple

On paper, swapping databases in Go looks trivial. database/sql is an interface. Change the driver, change the connection string, done.

In reality, the diff was 11 files and 708 lines.

Step 1: Swap the driver.

// Before
_ "modernc.org/sqlite"
DB, _ = sql.Open("sqlite", "./data.db")

// After
_ "github.com/lib/pq"
DB, _ = sql.Open("postgres", dsn)

Step 2: Build a DSN instead of a file path.

SQLite takes a filename. Postgres takes a connection string with five moving parts:

dsn := fmt.Sprintf("host=%s port=%s user=%s password=%s dbname=%s sslmode=disable",
    cfg.DBHost, cfg.DBPort, cfg.DBUser, cfg.DBPassword, cfg.DBName)

My config struct grew from DBPath string to five separate env vars. Every one of them needs a default, a validation, and a place to live in .env, docker-compose.yml, and CI.

Step 3: Rewrite every query.

This is where I got humbled. SQLite uses ? placeholders. Postgres uses $1, $2, $3:

// SQLite
query := `INSERT INTO entries (user_id, text, mood, category) VALUES (?, ?, ?, ?)`

// Postgres
query := `INSERT INTO entries (user_id, text, mood, category) VALUES ($1, $2, $3, $4)`

Every WHERE user_id = ? had to become WHERE user_id = $1. Miss one, and you get a runtime error that only surfaces when that specific handler runs.

Step 4: Rewrite every schema.

SQLite is loose with types. Postgres is strict.

-- SQLite
CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- Postgres
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    created_at TIMESTAMP DEFAULT NOW()
);

AUTOINCREMENT â†’ SERIAL. DATETIME â†’ TIMESTAMP. CURRENT_TIMESTAMP â†’ NOW(). Small changes. Each one a landmine if you forget.

The One That Stung

LastInsertId().

In SQLite:

result, err := DB.ExecContext(ctx, query, userID, text, mood, category)
id, err := result.LastInsertId()  // works

In Postgres: that method returns an error. The lib/pq driver doesn't support it. Because Postgres doesn't know what the "last" insert was â€” there's no global counter like SQLite has.

The Postgres way is to ask the database to hand back the ID as part of the insert:

query := `INSERT INTO entries (user_id, text, mood, category)
          VALUES ($1, $2, $3, $4) RETURNING id`

var id int64
err := DB.QueryRowContext(ctx, query, userID, text, mood, category).Scan(&id)

RETURNING id is Postgres-specific. It's also beautiful â€” one round trip instead of two, and you get the ID guaranteed to be the one you just inserted, even under concurrent load.

This is the kind of thing a tutorial never teaches you. You have to migrate a database to discover it.

The CI Rewrite

The last piece was GitHub Actions. My CI was running tests against SQLite files. I needed a real Postgres instance for every test run.

services:
  postgres:
    image: postgres:16
    env:
      POSTGRES_USER: testuser
      POSTGRES_PASSWORD: testpass
      POSTGRES_DB: testdb
    ports:
      - 5432:5432
    options: >-
      --health-cmd pg_isready
      --health-interval 10s
      --health-timeout 5s
      --health-retries 5

GitHub Actions spins up a Postgres container as a sidecar to my test job. The health check waits for it to be ready. My tests run against a real database. If they pass in CI, they'll pass in production â€” because the database is the same.

That felt like a milestone.

What This Actually Taught Me

I thought this was a migration. It was a lesson in what "production-ready" actually means.

SQLite is incredible â€” for prototypes. Fast, simple, zero setup. For learning Go, it removed every obstacle between me and my first working REST API.

Postgres is what production looks like. Connection pooling, concurrent writes, real constraints, explicit types, dedicated container in CI. Every "pain point" I hit was a concept I needed to learn anyway â€” just sooner than I wanted to.

The biggest mindset shift: my tests got honest. A test suite running against Postgres in CI is testing my code. A test suite running against SQLite was testing a fiction â€” a simpler world where concurrency didn't exist.

If you're building something you actually want to deploy, migrate early. The longer you wait, the more queries you write, the more schemas you create, the more rewriting you'll do.

I lost a weekend to this migration.

I gained a backend I can actually ship.

Up next: with Postgres in place, I finally tackled the thing I'd been avoiding for weeks â€” proper database migrations with golang-migrate. Because writing CREATE TABLE IF NOT EXISTS in Go code was a sin I was ready to confess.

My Server Was Silently Dropping Requests — Here's the One-Line Fix That Changed Everything

Abhishek Sharma — Thu, 23 Apr 2026 12:52:58 +0000

In Part 6, I added rate limiting and Redis. The API was getting real — pagination, caching, authentication, rate limiting. It handled traffic. It scaled horizontally.

Then I pressed Ctrl+C and realized something: every request in flight just vanished.

The Problem Nobody Warns You About

Here's what my server startup looked like before:

log.Printf("Server starting on port %s", port)
http.ListenAndServe(":"+port, nil)

Two lines. Works fine. Except when you stop it.

http.ListenAndServe blocks forever. When you press Ctrl+C, the process gets killed instantly. Any request that was mid-response? Gone. Any database transaction that was half-committed? Corrupted. Any user waiting for a response? Timeout.

In development this doesn't matter. In production, this is how you lose data.

Day 21: Teaching the Server How to Die

The fix required rethinking how the server starts. Instead of ListenAndServe (which blocks), I needed to:

Start the server in a goroutine (background)
Listen for shutdown signals on the main thread
When Ctrl+C hits, stop accepting new requests but finish current ones

// Step 1: Create a server (so we can call Shutdown later)
server := &http.Server{Addr: ":" + port}

// Step 2: Start in background
go func() {
    log.Printf("Server starting on port %s", port)
    if err := server.ListenAndServe(); err != http.ErrServerClosed {
        log.Fatalf("Server error: %v", err)
    }
}()

// Step 3: Wait for Ctrl+C
quit := make(chan os.Signal, 1)
signal.Notify(quit, os.Interrupt)
<-quit  // blocks here until signal received

That <-quit line is where I had my "aha" moment with Go channels. It's not a sleep. It's not polling. The goroutine just parks itself until a signal arrives. Zero CPU usage while waiting.

The Graceful Part

When Ctrl+C hits, the signal flows through the channel, and shutdown begins:

log.Println("Shutdown signal received...")

// Give in-flight requests 5 seconds to finish
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

// This is the magic line:
server.Shutdown(ctx)

server.Shutdown(ctx) does two things simultaneously:

Stops accepting new connections immediately
Waits for existing requests to complete (up to 5 seconds)

If a request is mid-response, it gets those 5 seconds to finish. If it takes longer — force close. No data loss in the normal case. No hanging forever in the worst case.

After that, close Redis, close the database, log "Server stopped gracefully", exit clean.

Day 22: The Health Check That Actually Checks

While I was thinking about server lifecycle, I looked at my health endpoint:

func HealthHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "OK")
}

This is lying. It says "OK" even if the database is down. Even if Redis is dead. It's not a health check — it's a health lie.

I replaced it with one that actually pings dependencies:

type HealthResponse struct {
    Status   string `json:"status"`
    Database string `json:"database"`
    Redis    string `json:"redis"`
}

func HealthHandler(w http.ResponseWriter, r *http.Request) {
    response := HealthResponse{
        Status:   "healthy",
        Database: "connected",
        Redis:    "connected",
    }

    if err := redis.Client.Ping(context.Background()).Err(); err != nil {
        response.Redis = "disconnected"
        response.Status = "unhealthy"
    }

    if err := db.DB.Ping(); err != nil {
        response.Database = "disconnected"
        response.Status = "unhealthy"
    }

    if response.Status == "unhealthy" {
        w.WriteHeader(http.StatusServiceUnavailable) // 503
    }
    json.NewEncoder(w).Encode(response)
}

Now when a load balancer hits /health, it gets a real answer:

{"status": "healthy", "database": "connected", "redis": "connected"}

Or:

{"status": "unhealthy", "database": "connected", "redis": "disconnected"}

The 503 status code tells the load balancer: "stop sending me traffic." That's how production systems route around failure — not by guessing, but by asking.

What I Learned

http.ListenAndServe is a learning tool, not a production tool. The moment your server handles real traffic, you need http.Server + Shutdown(). It's 15 extra lines of code. There's no excuse to skip it.

Channels aren't just for concurrency. <-quit is a channel used for coordination — the main goroutine waits for an OS signal without burning CPU. Channels are Go's answer to "how do goroutines talk to each other?"

Health checks should fail loudly. A health endpoint that always returns 200 is worse than no health endpoint at all. It gives you false confidence. If it can't verify dependencies, it should say so.

The Server Now

Ctrl+C pressed
  → Signal hits quit channel
  → Stop accepting new connections
  → Wait up to 5 seconds for in-flight requests
  → Close Redis
  → Close database
  → Exit 0

Clean lifecycle. No dropped requests. No corrupted transactions. And a health check that actually tells the truth.

What's Next

In Part 8, I'll cover Docker and Postgres — containerizing the entire stack and migrating from SQLite to a real database. The moment this thing stopped being a toy and started being deployable.

I Built Rate Limiting From Scratch in Go — Then Replaced It With Redis

Abhishek Sharma — Wed, 22 Apr 2026 12:12:11 +0000

In Part 5, I added pagination and in-memory caching. Both worked fine — until I thought about what happens with more than one server.

Three days, two rewrites, one lesson: in-memory is a local solution to a global problem.

Day 18: Rate Limiting From Scratch

I wanted to limit each IP to 100 requests per minute. The algorithm is called a fixed window — count requests in a time window, reset when the window expires.

I built it with a map and a sync.RWMutex:

type RateLimitEntry struct {
    count       int
    WindowStart time.Time
}

type RateLimit struct {
    users map[string]RateLimitEntry
    mu    sync.RWMutex
}

func (rl *RateLimit) IsAllowed(key string, limit int, window time.Duration) bool {
    rl.mu.Lock()
    defer rl.mu.Unlock()

    entry, exists := rl.users[key]
    now := time.Now()

    // New IP or expired window → start fresh
    if !exists || now.After(entry.WindowStart.Add(window)) {
        rl.users[key] = RateLimitEntry{count: 1, WindowStart: now}
        return true
    }

    if entry.count >= limit {
        return false // blocked
    }

    entry.count++
    rl.users[key] = entry
    return true
}

Wiring it up as middleware was the satisfying part — one function wraps another:

http.HandleFunc("/entries", handlers.RateLimitMiddleware(
    handlers.LoggingMiddleware(
        handlers.AuthMiddleware(handler),
    ),
))

The API now returns 429 Too Many Requests if you hammer it. Done. Except...

The Problem I Didn't Solve

I was writing system design notes alongside the code, and I drew this:

Load Balancer
    /        \
Server A    Server B
count: 50   count: 50   ← each has its OWN memory

User makes 100 requests. 50 go to A, 50 to B. Each server thinks "only 50 — under limit!". The user bypassed rate limiting entirely.

Same problem with caching: every server has its own in-memory cache. One server caches a count. Another server doesn't. They disagree. Your data is inconsistent.

In-memory solutions break the moment you run more than one instance.

Days 19-20: Replacing Everything With Redis

Redis is a shared, external store. Both servers read from and write to the same place. Problem solved.

Cache before (in-memory):

type Cache struct {
    data map[string]CacheEntry
    mu   sync.RWMutex
}

func (c *Cache) Get(key string) (interface{}, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    entry, exists := c.data[key]
    if !exists || time.Now().After(entry.Expiration) {
        return nil, false
    }
    return entry.value, true
}

Cache after (Redis):

func Get(key string) (string, bool) {
    result, err := redis.Client.Get(context.Background(), key).Result()
    if err == goredis.Nil {
        return "", false // key doesn't exist
    }
    if err != nil {
        return "", false // other error
    }
    return result, true
}

Same function signature. The caller — entries.go — didn't change at all. That's separation of concerns working exactly as intended.

Rate limiting before (in-memory): the IsAllowed function with sync.RWMutex above.

Rate limiting after (Redis):

func IsAllowed(key string, limit int, window time.Duration) bool {
    redisKey := "ratelimit:" + key

    // Atomic increment — no mutex needed
    count, err := redis.Client.Incr(context.Background(), redisKey).Result()
    if err != nil {
        return true // fail open if Redis is down
    }

    // First request in window → set expiry
    if count == 1 {
        redis.Client.Expire(context.Background(), redisKey, window)
    }

    return count <= int64(limit)
}

INCR is atomic in Redis. No mutex. No struct. No map. Redis handles the concurrency.

What I Learned

sync.RWMutex is for single-process concurrency. Multiple goroutines in one server — yes. Multiple servers — no. When you need distributed state, you need a distributed store.

The same API surface, different backend. cache.Get(key) works whether the backend is a map or Redis. The handlers don't know or care. That's the value of keeping the interface clean.

Fail open vs fail closed. If Redis goes down, my rate limiter returns true (allow the request). This is a deliberate choice — I'd rather serve traffic than block everyone because of an infra failure. For some use cases (auth, payments) you'd fail closed. Know which you need.

goredis.Nil is a sentinel error. When a key doesn't exist, Redis returns a specific error value — not an empty string. This tripped me up the first time.

The Architecture Now

Load Balancer
    /        \
Server A    Server B
    \        /
      Redis
   (shared state)

One Redis. Both servers read the same cache, increment the same counters. Scale horizontally without breaking anything.

What's Next

In Part 7, I'll cover graceful shutdown and health checks — what happens when your server needs to stop without dropping requests in flight, and how to expose a /health endpoint that actually checks your dependencies.

This is Part 6 of "Learning Go in Public". Part 1 | Part 2 | Part 3 | Part 4 | Part 5

What Happens When Your API Has 10,000 Rows? I Added Pagination and Caching to Find Out

Abhishek Sharma — Tue, 21 Apr 2026 11:10:13 +0000

In Part 4, I finished full CRUD and wrote my first Go tests. The API worked — but I was the only user, hitting it from my terminal with 10 test entries.

Then I asked: what happens when there are 10,000 rows?

Two days, two features. Both taught me things I didn't expect.

Day 16: Pagination

GET /entries was returning every row in the database for a user. Fine when I have 10 test entries. A disaster with 10,000.

Pagination is simple in principle — you add ?page=1&limit=10 to the URL and only fetch that slice. The implementation taught me something about Go's "fail gracefully" philosophy:

page := 1   // default
limit := 10 // default

pageStr := r.URL.Query().Get("page")
if pageStr != "" {
    if p, err := strconv.Atoi(pageStr); err == nil && p > 0 {
        page = p
    }
}

limitStr := r.URL.Query().Get("limit")
if limitStr != "" {
    if l, err := strconv.Atoi(limitStr); err == nil && l > 0 && l <= 100 {
        limit = l
    }
}

Notice what's NOT there: no 400 Bad Request if you pass ?page=abc. Invalid params just silently fall back to defaults. I went back and forth on this — should I return an error?

Decided no. Pagination params are optional hints, not required inputs. If you pass garbage, you get the first page. The API keeps working. This feels more correct for a read endpoint.

The database query uses LIMIT and OFFSET:

SELECT * FROM entries 
WHERE user_id = $1 
ORDER BY created_at DESC 
LIMIT $2 OFFSET $3

Where OFFSET = (page - 1) * limit. The response now includes total, page, limit, and entries — so clients can calculate how many pages exist.

Day 17: In-Memory Caching

Pagination meant a COUNT query on every GET request to return the total. SELECT COUNT(*) FROM entries WHERE user_id = ? is cheap with 10 rows, expensive at scale.

I built a simple in-memory cache:

type CacheEntry struct {
    value      interface{}
    Expiration time.Time
}

type Cache struct {
    data map[string]CacheEntry
    mu   sync.RWMutex  // ← this is the key part
}

func (c *Cache) Get(key string) (interface{}, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()

    entry, exists := c.data[key]
    if !exists || time.Now().After(entry.Expiration) {
        return nil, false
    }
    return entry.value, true
}

The sync.RWMutex was new to me. Regular Mutex blocks everything — only one goroutine at a time. RWMutex is smarter: multiple goroutines can read simultaneously, but writing requires exclusive access.

For a cache that's read far more often than written, this matters.

Cache invalidation: when a user creates or deletes an entry, I delete their cached count:

cache.Delete(fmt.Sprintf("count:user:%d", userID))

The cache key includes the user ID so different users never see each other's counts. Simple, but it took me a few minutes to think through why I needed that.

What I Learned

Pagination defaults beat errors. For optional hints like page and limit, failing gracefully is better UX than returning a 400. Save strict validation for required inputs.

sync.RWMutex vs sync.Mutex. Read-heavy data structures should use RWMutex. Multiple goroutines can read simultaneously — only writes need exclusive access.

Cache keys need scope. count:user:42 not just count. Otherwise all users share the same cached value — a subtle bug that only shows up with multiple users.

The API Now

GET /entries?page=1&limit=10   → paginated, cached COUNT
POST /entries                  → creates entry, invalidates cache
DELETE /entries?id=X           → deletes entry, invalidates cache

The API no longer dumps every row on every request. The database isn't hit for the count on repeated reads. Small changes, but the kind that matter when traffic is real.

What's Next

In Part 6, I'll cover rate limiting and Redis — the week I started thinking about abuse prevention and why in-memory solutions break the moment you run more than one server instance.

This is Part 5 of the "Learning Go in Public" series. Part 1 | Part 2 | Part 3 | Part 4

Tests, UPDATE, DELETE — And the Refactor I Didn't Plan

Abhishek Sharma — Mon, 20 Apr 2026 11:04:33 +0000

In Part 3, I built authentication — JWT tokens, bcrypt hashing, middleware that wraps handlers like Russian dolls. The API had four endpoints and was fully protected.

But it could only create and read entries. No updating. No deleting. And zero tests.

This post is about the week I added the missing CRUD operations, wrote my first Go tests, and accidentally refactored the entire project structure — all because one test file exposed a design flaw I couldn't unsee.

UPDATE: Harder Than I Expected

Adding a PATCH endpoint sounded simple. It wasn't. The tricky part wasn't the database query — it was ownership validation.

When a user sends PATCH /entries?id=5, I can't just update entry 5. I need to verify that entry 5 belongs to this user. Otherwise any authenticated user could edit anyone's entries.

Here's the handler:

func UpdateEntry(w http.ResponseWriter, r *http.Request) {
    // Parse entry ID from query string
    entryId, err := strconv.Atoi(r.URL.Query().Get("id"))

    // Get user ID from context (set by AuthMiddleware)
    userID := r.Context().Value("user_id").(int64)

    // Validate all fields...
    if req.Text == "" { /* 400 */ }
    if req.Mood < 1 || req.Mood > 10 { /* 400 */ }

    // The key line — WHERE clause checks BOTH id AND user_id
    rowsAffected, err := db.UpdateEntry(ctx, entryId, userID, 
        req.Text, req.Mood, req.Category)

    if rowsAffected == 0 {
        // Entry doesn't exist OR doesn't belong to this user
        errorResponse(w, http.StatusNotFound, 
            "Entry not found or access denied")
        return
    }
}

The database query uses WHERE id = ? AND user_id = ?. If the entry exists but belongs to someone else, rowsAffected is 0. Same response as "entry doesn't exist." This is intentional — you don't want to leak information about other users' data.

I wrote an 8-test PowerShell script to verify every edge case: update your own entry, try to update someone else's, update with missing fields, update with mood out of range. All passing.

DELETE: The Same Pattern, Simpler

Once UPDATE worked, DELETE took 20 minutes. Same ownership pattern:

func DeleteEntry(w http.ResponseWriter, r *http.Request) {
    entryId, _ := strconv.Atoi(r.URL.Query().Get("id"))
    userID := r.Context().Value("user_id").(int64)

    rowsAffected, err := db.DeleteEntry(ctx, entryId, userID)

    if rowsAffected == 0 {
        errorResponse(w, http.StatusNotFound, 
            "Entry not found or access denied")
        return
    }

    respondJSON(w, http.StatusOK, CreateEntryResponse{
        Success: true,
        Message: "Entry deleted successfully",
    })
}

Same WHERE id = ? AND user_id = ?. Same ownership check. Same ambiguous error message. I didn't realize it at the time, but this was my first Go pattern — I was copying the structure from UPDATE and it just worked.

Seven tests. All green.

The Accidental Refactor

Here's where things got interesting. I was writing tests when I noticed something ugly: my models/entry.go had database functions mixed in with struct definitions. The Entry struct and InsertEntry() were in the same file.

models/
  entry.go    ← struct definitions AND database functions??
  models.go   ← more structs

This was wrong. The whole point of separating models/ from db/ is separation of concerns. Models define what data looks like. DB defines how it's stored and retrieved.

So I refactored:

models/
  models.go   ← ALL struct definitions (Entry, User, requests, responses)
db/
  db.go       ← ALL database operations (Insert, Update, Delete, Get)

I moved every database function from models/entry.go into db/db.go. Deleted the old file. Updated all imports.

This wasn't planned. It happened because writing tests forced me to think about where things belong. When you import a package for testing, messy boundaries become obvious.

My First Real Tests

I had been testing with PowerShell scripts — curl-style commands that hit a running server. Those are integration tests. Useful, but slow and fragile.

Go has testing and httptest built into the standard library. No Jest, no Mocha, no test runner to install. You just:

Create a file ending in _test.go
Write functions starting with Test
Run go test

Here's my first handler test:

func TestCreateEntry(t *testing.T) {
    body := strings.NewReader(
        `{"text":"feeling good","mood":8,"category":"mood"}`,
    )

    // Create a fake HTTP request
    req := httptest.NewRequest(http.MethodPost, "/entries", body)

    // Inject user_id into context (normally AuthMiddleware does this)
    ctx := context.WithValue(req.Context(), "user_id", int64(1))
    req = req.WithContext(ctx)

    // Record the response
    rec := httptest.NewRecorder()

    // Call the handler directly — no server needed
    CreateEntry(rec, req)

    // Assert
    if rec.Code != http.StatusCreated {
        t.Errorf("expected 201, got %d", rec.Code)
    }
}

Two things blew my mind:

httptest.NewRequest — you create a fake HTTP request with any method, URL, and body. No actual network call. No server running. It's just a struct.

httptest.NewRecorder — captures whatever the handler writes. Status code, headers, body. You inspect it after the handler returns.

The test for invalid input was almost as satisfying:

func TestCreateEntry_MissingText(t *testing.T) {
    body := strings.NewReader(`{"text":"","mood":8,"category":"mood"}`)
    req := httptest.NewRequest(http.MethodPost, "/entries", body)
    ctx := context.WithValue(req.Context(), "user_id", int64(1))
    req = req.WithContext(ctx)
    rec := httptest.NewRecorder()

    CreateEntry(rec, req)

    if rec.Code != http.StatusBadRequest {
        t.Errorf("expected 400, got %d", rec.Code)
    }
}

Empty text → 400. Invalid mood → 400. Missing auth → 401. Each scenario is three lines of setup, one function call, one assertion.

Coming from JavaScript testing where you install Jest, configure Babel, mock fetch, set up test databases... Go's approach felt almost too simple. But it works.

What I Learned This Week

The ownership pattern is reusable. WHERE id = ? AND user_id = ? with rowsAffected == 0 handles both "not found" and "not yours" in one query. I've used this pattern three times now (GET, UPDATE, DELETE) and it's always the same.

Refactoring happens when you test. I didn't plan to restructure the project. But the moment I tried to write a test that imported models, the messy boundaries became obvious. Tests are a design feedback tool, not just a verification tool.

Go testing is minimal and that's the point. No assertions library. No mocking framework. Just if got != want { t.Errorf() }. It forces you to write tests that are readable without any DSL knowledge.

Where the API Stands Now

POST   /register       → Create account (public)
POST   /login          → Get JWT token (public)
POST   /entries        → Create entry (protected)
GET    /entries        → List entries (protected)
PATCH  /entries?id=X   → Update entry (protected + ownership)
DELETE /entries?id=X   → Delete entry (protected + ownership)
GET    /health         → Health check (public)

Six real endpoints. Full CRUD. Authentication. Authorization with ownership validation. 18 tests passing. And a project structure that finally makes sense.

What's Next

In Part 5, I'll cover the week I added pagination, caching, and rate limiting — the features that made me think about what happens when this API isn't just me hitting it from PowerShell anymore.

This is Part 4 of the "Learning Go in Public" series. Part 1 | Part 2 | Part 3

Building Authentication From Scratch in Go — No Libraries, No Magic

Abhishek Sharma — Fri, 17 Apr 2026 13:18:54 +0000

In Part 2, I had a working REST API with two endpoints. You could create entries and query them. But anyone could hit the API — no login, no tokens, no protection.

This post is about the day I decided to build authentication from scratch, and the Go pattern that changed how I think about HTTP servers.

The Plan

I needed three things:

Register — hash a password, save the user
Login — verify credentials, return a JWT token
Middleware — block unauthenticated requests before they reach any handler

No auth libraries. No Passport.js equivalent. Just golang-jwt/jwt for token creation and golang.org/x/crypto/bcrypt for password hashing.

Registration: My First Time Hashing a Password

Here's what the register handler looked like:

func Register(w http.ResponseWriter, r *http.Request) {
    var req RegisterRequest
    json.NewDecoder(r.Body).Decode(&req)

    // Validate
    if req.Email == "" { /* 400 */ }
    if !strings.Contains(req.Email, "@") { /* 400 */ }
    if len(req.Password) < 6 { /* 400 */ }

    // Hash password — NEVER store plain text
    passwordHash, err := bcrypt.GenerateFromPassword(
        []byte(req.Password), bcrypt.DefaultCost,
    )

    // Save to database
    userID, err := db.CreateUser(req.Email, string(passwordHash))
}

Two things I learned here:

bcrypt.DefaultCost is 10. That means it runs the hashing algorithm 2^10 = 1,024 times. Slow on purpose — makes brute-force attacks impractical. I spent 20 minutes reading about why a slower hash function is a feature, not a bug.

[]byte() everywhere. bcrypt's functions take byte slices, not strings. Coming from JavaScript where everything is just a string, I kept forgetting to convert. Go makes you think about data types at every step.

Login: Creating My First JWT

The login flow taught me more about Go than any tutorial:

// 1. Get user from database
userID, passwordHash, err := db.GetUserByEmail(req.Email)

// 2. Compare password with stored hash
err = bcrypt.CompareHashAndPassword(
    []byte(passwordHash), []byte(req.Password),
)

// 3. Create JWT claims
claims := jwt.MapClaims{
    "user_id": userID,
    "exp":     time.Now().Add(24 * time.Hour).Unix(),
}

// 4. Sign the token
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
tokenString, err := token.SignedString([]byte(secret))

I left this comment in my code at the time:

// Why Unix()? JWT needs simple numbers, not complex Go time objects
// Example: time.Now().Unix() = 1736359530 (just a number)
// Add 24 hours = add 86400 seconds (24 * 60 * 60 = 86400)

Again — verbose, maybe obvious to experienced devs. But I was explaining JWT to myself while building it. That's the whole point of learning in public.

One security detail I got right: the error message for a wrong password is "Invalid email or password" — same as for a non-existent email. You never want to reveal whether an account exists.

The Middleware Pattern That Changed Everything

This is the part I'm most proud of from this phase. Go doesn't have middleware built in like Express. You build it yourself:

func AuthMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        // 1. Get token from "Authorization: Bearer <token>"
        authHeader := r.Header.Get("Authorization")
        tokenString := strings.TrimPrefix(authHeader, "Bearer ")

        // 2. Validate token
        claims, err := validateToken(tokenString)
        if err != nil {
            errorResponseAuth(w, http.StatusUnauthorized, "Invalid token")
            return
        }

        // 3. Extract user_id and add to request context
        userID := claims["user_id"].(float64)
        ctx := context.WithValue(r.Context(), "user_id", int64(userID))

        // 4. Call next handler with updated context
        next(w, r.WithContext(ctx))
    }
}

Read that again. A function that takes a handler and returns a new handler. The returned handler does the auth check first, and only calls the original handler if the token is valid.

In main.go, using it looks like this:

// Public routes — no protection
http.HandleFunc("/register", handlers.Register)
http.HandleFunc("/login", handlers.Login)

// Protected route — wrapped with AuthMiddleware
http.HandleFunc("/entries", handlers.AuthMiddleware(func(w http.ResponseWriter, r *http.Request) {
    if r.Method == http.MethodPost {
        handlers.CreateEntry(w, r)
    } else if r.Method == http.MethodGet {
        handlers.GetEntries(w, r)
    }
}))

AuthMiddleware(handler) — that's it. One wrapper function. No framework, no plugin system, no decorator syntax. Just a function wrapping another function.

This is the moment Go clicked for me at a deeper level. Functions are values. You can pass them around, wrap them, chain them. Middleware isn't a framework feature — it's just how functions work.

The `context.WithValue` Trick

The most clever part of Go's auth pattern: how you pass the user ID from middleware to the handler.

// Middleware sets it:
ctx := context.WithValue(r.Context(), "user_id", int64(userID))
next(w, r.WithContext(ctx))

// Handler reads it:
userID := r.Context().Value("user_id").(int64)

No global variables. No session objects. The user ID travels with the request itself. Every handler that needs to know who's making the request just reads it from the context.

Coming from Express where you'd do req.user = decoded, this felt more explicit and safer. The data is scoped to the request, not bolted onto a mutable object.

One Thing That Tripped Me Up

JWT numbers come back as float64, not int64. This line:

userID, ok := claims["user_id"].(float64)

I originally wrote .(int64) and couldn't figure out why it kept failing. Turns out JSON (which JWT uses internally) doesn't distinguish between integers and floats — everything is a number. Go's JSON decoder maps all numbers to float64.

Took me an hour of debugging. Now I'll never forget it.

What the API Looked Like After This

POST /register  → Create account (public)
POST /login     → Get JWT token (public)
POST /entries   → Create entry (protected)
GET  /entries   → List entries (protected)
GET  /health    → Health check (public)
GET  /ping      → Ping (public)

Four real endpoints. Authentication. Authorization. No frameworks. Just Go's standard library plus two packages for JWT and bcrypt.

What's Next

In Part 4, I'll cover the week I added testing, UPDATE, and DELETE — and why writing tests after the code changed how I thought about designing handlers.

This is Part 3 of the "Learning Go in Public" series. Part 1 | Part 2

I Stopped Watching Tutorials and Started Building a REST API in Go

Abhishek Sharma — Thu, 16 Apr 2026 13:32:21 +0000

In my last post, I talked about my first week learning Go — the confusion, the messy first commit, and why I picked Go over sticking with JavaScript.

This post is about the moment things changed: I stopped writing practice files and started building a real project.

The Decision

After a week of writing structs.go, maps-practice.go, and interfaces-tutorial.go, I was learning syntax but not learning to build. I could explain what a goroutine is but couldn't wire up an HTTP endpoint.

So I picked a project: a personal analytics backend. A REST API where I could log daily entries — mood, productivity notes, whatever — and query them later. Simple enough to be achievable, real enough to force me to learn.

Day 1: The Skeleton

My first backend commit had just 3 files that mattered:

cmd/server/main.go — the entry point:

func main() {
    err := godotenv.Load()
    if err != nil {
        log.Println("No .env file found")
    }

    dbPath := os.Getenv("DB_PATH")
    if dbPath == "" {
        dbPath = "./data.db"
    }
    err = db.InitDB(dbPath)
    if err != nil {
        log.Fatalf("Failed to initialize database: %v", err)
    }
    defer db.CloseDB()

    http.HandleFunc("/health", handlers.HealthHandler)
    http.HandleFunc("/ping", handlers.PingHandler)

    log.Printf("Server starting on port %s", port)
    http.ListenAndServe(":"+port, nil)
}

Two endpoints. /health returns "ok". /ping returns the current time. That's it. That was my entire backend.

But here's what I learned just from this:

http.HandleFunc registers a function to a URL path — Go's router is that simple
http.ListenAndServe blocks and listens forever — no framework needed
defer db.CloseDB() — Go's defer runs when the function exits, perfect for cleanup

internal/db/db.go — database connection:

I used SQLite because it's a single file — no Docker, no Postgres setup, no connection strings. Just ./data.db.

func InitDB(path string) error {
    var err error
    DB, err = sql.Open("sqlite", path)
    if err != nil {
        return fmt.Errorf("failed to open database: %w", err)
    }
    // Create tables
    _, err = DB.Exec(`CREATE TABLE IF NOT EXISTS entries (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        user_id INTEGER NOT NULL,
        text TEXT NOT NULL,
        mood INTEGER CHECK(mood >= 1 AND mood <= 10),
        created_at DATETIME DEFAULT CURRENT_TIMESTAMP
    )`)
    return err
}

The %w in fmt.Errorf wraps the original error — you can unwrap it later. I didn't understand why this mattered until weeks later when I needed to check error types.

Day 2: The First Real Endpoint

This is where it clicked. I wrote POST /entries — my first handler that actually does something:

func CreateEntry(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodPost {
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
        return
    }

    var req CreateEntryRequest
    err := json.NewDecoder(r.Body).Decode(&req)
    if err != nil {
        respondJSON(w, http.StatusBadRequest, CreateEntryResponse{
            Success: false,
            Message: "Invalid request body",
        })
        return
    }

    // Validate: user_id > 0, text not empty, mood 1-10
    if req.UserID <= 0 { /* return 400 */ }
    if req.Text == "" { /* return 400 */ }
    if req.Mood < 1 || req.Mood > 10 { /* return 400 */ }

    // Insert into database
    id, err := db.InsertEntry(req.UserID, req.Text, req.Mood)
    if err != nil {
        respondJSON(w, http.StatusInternalServerError, CreateEntryResponse{
            Success: false,
            Message: "Failed to create entry",
        })
        return
    }

    respondJSON(w, http.StatusCreated, CreateEntryResponse{
        Success: true,
        Message: "Entry created",
        ID:      id,
    })
}

Look at the pattern: validate → process → respond. Early returns everywhere. No nesting. No else blocks. If something's wrong, respond with an error and return immediately.

This is the Go way, and it's brilliant. Coming from JavaScript where I'd chain .then().catch() or wrap everything in try/catch, this felt refreshing. Every failure point is explicit.

What I Learned About `http.ResponseWriter` vs `*http.Request`

This confused me for days. Why is w not a pointer but r is?

*http.Request is a pointer to a struct — it's huge (headers, URL, cookies, body). Copying it would be wasteful.
http.ResponseWriter is an interface. In Go, interfaces are already a small wrapper that points to the real data. You don't need a pointer to a pointer.

The rule I learned: If you see a type without `` but you can still call methods that modify things, it's probably an interface.*

The Comments I Left for Myself

My code from this commit is packed with comments like:

// "Read the JSON data from the request and put it into our req variable."
// Step-by-step:
// r.Body = the data the client sent
// json.NewDecoder(r.Body) = create a JSON reader
// .Decode(&req) = convert JSON into our struct

These comments are verbose and probably "wrong" by clean code standards. But they're exactly what I needed at the time — explanations in my own words, written while the concept was clicking.

I'm keeping them. They're documentation of learning, not documentation of code.

The Moment It Felt Real

I ran go run cmd/server/main.go, opened another terminal, and typed:

curl -X POST http://localhost:8080/entries \
  -H "Content-Type: application/json" \
  -d '{"user_id": 1, "text": "First entry!", "mood": 8}'

And got back:

{"success": true, "message": "Entry created", "id": 1}

Data went into a real database. I could query it back with GET /entries. It was two endpoints and a SQLite file, but it was mine. I built it with zero frameworks, just Go's standard library.

That's when Go stopped being a language I was studying and became a tool I was building with.

What's Next

In Part 3, I'll cover the scariest part of this project: adding authentication from scratch. JWT tokens, bcrypt password hashing, and the middleware pattern that changed how I think about HTTP — all without a single auth library.

This is Part 2 of the "Learning Go in Public" series. Part 1 is here.