DEV Community: Boluwatife Adewusi

Memoization in React: Or How I Thought I Optimized My App (But Mostly Just Felt Productive)

Boluwatife Adewusi — Thu, 08 Jan 2026 18:08:10 +0000

If you’ve been writing React for a while, there’s a phase you inevitably enter.

It’s the “performance phase.”

This is where you stop worrying about getting things to work and start worrying about getting things to work fast. You start side-eyeing re-renders like they owe you money. You open React DevTools more than you open Slack. And at some point, you Google:

“How to prevent re-renders in React”

And React, in its infinite wisdom, responds with three magical words:

useMemo
useCallback
memo

You read a few blog posts. You watch a YouTube video at 1.25x speed. You sprinkle some memoization into your code like seasoning.

✨ Optimized. ✨

Or… so you think.

That was me. For a long time.

I felt like I was writing performant React. But recently, I decided to stop trusting vibes and actually observe how React behaves in a few scenarios.

What I found was… humbling.

Turns out, I had been “optimizing” my app in ways that made me feel productive but didn’t actually do what I thought they did.

So today, I want to walk you through some not-so-obvious misconceptions about memoization in React, using this repo as our playground:

👉 Repo: https://github.com/bolusarz/react-memo-app

And yes, this is me bringing you along on my learning journey. If you disagree with anything—or if something clicks for you—please yell (politely) in the comments.

Before We Get Fancy, Let’s Agree on Some Facts

A React component re-renders when:

Its internal state changes
Its parent re-renders

Some people add a third one:

When its props change

Personally, I think #2 already covers that. If you disagree, feel free to fight me in the comments. I’m open. 😄

Keep these two rules in mind—we’ll keep coming back to them like a lecturer pointing at the same slide over and over saying “this will be on the exam.”

Misconception #1

“Passing memoized values into a component prevents re-renders”

Short answer: Nope.

Long answer: Let me show you why I fell for this too.

Switch to the without-memoized-component branch in the repo. You’ll see two components:

`memoized-component.tsx`

(pretend I’m dramatically pointing at it)

`App.tsx`

(nod thoughtfully)

Notice something important in App.tsx:

We’re using useCallback before passing a function down as a prop.

At this point, past-me was already celebrating.

“The function is memoized. React won’t re-render the child. I am a performance genius.”

Now click the count button.

The child component re-renders every single time.

“But wait,” you say, adjusting your glasses,

“the function isn’t changing!”

Correct. Gold star ⭐

The function reference is stable.

But remember the rules.

Go back. Look at rule #2.

A component re-renders when its parent re-renders.

The parent’s state changed.

The parent re-rendered.

So the child re-rendered.

useCallback didn’t fail you.

Your expectations did. (Mine too.)

In this scenario, useCallback is basically emotional support—it makes you feel better but doesn’t actually stop anything.

“So… how do we fix it?”

Easy.

Wrap the child component with memo.

Now refresh the app (yes, actually refresh it, go on).

Click the button again.

No re-render.

Now we’ve achieved what we thought we had achieved earlier.

The lesson here:

Memoizing props without memoizing the component does absolutely nothing for re-renders.

Misconception #2

“If I memoize a component, I’m safe”

Ah yes. The other side of the trap.

memo only prevents re-renders when props don’t change.

And React checks this using shallow comparison.

So if you do this:

Pass an inline function
Pass a freshly created object
Pass a derived value that isn’t memoized

React sees:

“New reference? Cool. Re-render.”

At that point, your memo wrapper is just decorative.

You can test this yourself:

Remove useCallback from App.tsx
Click the button
Watch the render count climb like it’s training for cardio

The painful truth

Memoizing a component without memoizing the values you pass into it is like locking your front door and leaving the windows wide open.

Looks secure. Isn’t.

So… Should We Memoize Everything?

Please don’t.

That’s not optimization, that’s a future bug report waiting to happen.

Memoization has:

A mental cost
A maintenance cost
And sometimes even a performance cost

It shines only when:

Re-renders are expensive
Props are stable
You’ve measured a real problem (not just a feeling)

I’ll dive deeper into when memoization actually makes sense in another article.

Final Thoughts (From Someone Who Learned the Hard Way)

For a long time, I thought I was writing performant React because I was using the right tools.

What I wasn’t doing was:

Observing behavior
Questioning assumptions
Understanding why React was re-rendering

Memoization isn’t magic.

It’s just a tool.

And like all tools, it works best when you actually know what it does.

If I got anything wrong, misunderstood something, or if this post helped you see memoization differently, drop a comment. I’d genuinely love to hear your thoughts.

See you in the next one 👋

Building Web Servers from First Principles (Part 7)

Boluwatife Adewusi — Wed, 17 Sep 2025 23:34:45 +0000

In Chapter 6, we built a functional JSON API that can create and read users. But production servers need more than just business logic - they need logging, error handling, performance monitoring, and other cross-cutting concerns.

Today, we'll implement middleware - the backbone of production web servers that handles these concerns automatically for every request.

What We've Built So Far

From previous chapters:

✅ Complete JSON API with CRUD operations
✅ Dynamic routing and parameter extraction
✅ Request body parsing and validation
❌ Request/response logging
❌ Error recovery and graceful error handling
❌ Performance monitoring

Understanding Middleware

Middleware are functions that sit between the incoming request and your handler. They can:

Pre-process requests (logging, authentication, validation)
Post-process responses (logging, formatting, caching)
Handle errors (panic recovery, error formatting)
Add functionality (timing, metrics, CORS headers)

Think of middleware as layers of an onion - each request passes through multiple layers before reaching your handler, then back through the layers to send the response.

Middleware Pattern in Go

In Go, middleware follows this pattern:

type Middleware func(HandlerFunc) HandlerFunc

A middleware is a function that:

Takes a handler function as input
Returns a new handler function as output
The returned handler can do work before/after calling the original handler

Building Our First Middleware: Request Logging

Let's start with the simplest middleware - logging incoming requests. Create middleware.go:

package main

import (
    "log"
    "net/http"
    "time"
)

type Middleware func(HandlerFunc) HandlerFunc

func RequestLoggingMiddleware(next HandlerFunc) HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        log.Printf("%s %s", r.Method, r.URL.Path)
        next(w, r)  // Call the actual handler
    }
}

How this works:

RequestLoggingMiddleware receives the next handler (next)
It returns a new function that logs the request, then calls next
The new function has the same signature as a regular handler

Adding Middleware Support to Our Router

We need to modify our router to support middleware. Update router.go:

type Router struct {
    routes      map[string]map[string]HandlerFunc
    middlewares []Middleware  // Add this field
}

func (r *Router) Use(middleware Middleware) {
    r.middlewares = append(r.middlewares, middleware)
}

Now update the ServeHTTP method to apply middleware:

func (r *Router) ServeHTTP(w http.ResponseWriter, req *http.Request) {
    handler, err := r.resolveRoute(req)

    if err != nil {
        handler = r.notFoundHandler
    }

    // Apply all middlewares in order
    for _, middleware := range r.middlewares {
        handler = middleware(handler)
    }

    handler(w, req)
}

func (r *Router) notFoundHandler(w http.ResponseWriter, req *http.Request) {
    w.WriteHeader(http.StatusNotFound)
    w.Write([]byte("route not found"))
}

Don't forget to add the missing import and remove the log statement from resolveRoute:

import (
    "context"
    "fmt"
    "net/http"  // Remove the log import from here
    "strings"
)

// In resolveRoute function, remove this line:
// log.Printf("%s %s", method, path)

Testing Request Logging Middleware

Update main.go to use our middleware:

func setupRoutes(s *Server) {
    s.Router.Use(RequestLoggingMiddleware)
    s.Router.POST("/echo", echo)
    s.Router.GET("/users/:id", getUsers)
    s.Router.POST("/users", createUser)
}

Test it:

go run .

Make some requests:

curl http://localhost:3000/users/1
curl -X POST http://localhost:3000/users -H "Content-Type: application/json" -d '{"name":"Test","email":"test@example.com"}'

You should see logs like:

2024/09/14 15:30:45 GET /users/1
2024/09/14 15:30:50 POST /users

Great! Our middleware is working.

Building Timing Middleware

Let's add performance monitoring by measuring how long each request takes:

func TimingMiddleware(next HandlerFunc) HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        next(w, r)  // Execute the handler
        elapsed := time.Since(start)
        log.Printf("Request took %v seconds", elapsed.Seconds())
    }
}

Add it to your routes:

func setupRoutes(s *Server) {
    s.Router.Use(RequestLoggingMiddleware)
    s.Router.Use(TimingMiddleware)
    s.Router.POST("/echo", echo)
    s.Router.GET("/users/:id", getUsers)
    s.Router.POST("/users", createUser)
}

Test it and you'll see timing logs:

2024/09/14 15:31:15 GET /users/1
2024/09/14 15:31:15 Request took 0.000123 seconds

Building Response Logging Middleware

Request logging shows what's coming in, but we also want to see what's going out. This is trickier because we need to capture both the status code and response body.

We need to create a custom ResponseWriter that wraps the original one:

type responseWriter struct {
    http.ResponseWriter
    statusCode int
    body       []byte
}

func (rw *responseWriter) WriteHeader(code int) {
    rw.statusCode = code
    rw.ResponseWriter.WriteHeader(code)
}

func (rw *responseWriter) Write(body []byte) (int, error) {
    rw.body = append(rw.body, body...)
    return rw.ResponseWriter.Write(body)
}

func ResponseLoggingMiddleware(next HandlerFunc) HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        wrapped := &responseWriter{
            ResponseWriter: w,
            statusCode:     http.StatusOK,  // Default status
        }

        next(wrapped, r)  // Pass our wrapped writer to the handler

        log.Printf("%s %s - Status: %d, Body: %s",
            r.Method, r.URL.Path, wrapped.statusCode,
            string(wrapped.body))
    }
}

How this works:

We create a custom responseWriter that wraps the original
It captures the status code in WriteHeader()
It captures the response body in Write()
After the handler runs, we log both pieces of information

Add it to your middleware stack:

func setupRoutes(s *Server) {
    s.Router.Use(RequestLoggingMiddleware)
    s.Router.Use(ResponseLoggingMiddleware)
    s.Router.Use(TimingMiddleware)
    // ... routes
}

Add the required imports:

import (
    "log"
    "net/http"
    "runtime/debug"  // We'll need this for the next middleware
    "time"
)

Test it and you'll see detailed response logs:

2024/09/14 15:32:20 GET /users/1
2024/09/14 15:32:20 GET /users/1 - Status: 200, Body: {"data":{"id":1,"name":"John Doe","email":"johndoe@gmail.com"}}
2024/09/14 15:32:20 Request took 0.000089 seconds

Building Panic Recovery Middleware

This is the most important middleware for production - it catches panics and prevents your server from crashing:

func PanicRecoveryMiddleware(next HandlerFunc) HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if err := recover(); err != nil {
                log.Printf("Panic recovered: %v\n%s", err, debug.Stack())

                w.Header().Set("Content-Type", "application/json")
                w.WriteHeader(http.StatusInternalServerError)
                w.Write([]byte(`{"error": "Internal server error"}`))
            }
        }()

        next(w, r)
    }
}

How this works:

defer func() runs after the handler completes (or panics)
recover() catches any panic that occurred
We log the error and stack trace for debugging
We send a proper JSON error response to the client
The server stays running!

Let's test panic recovery by adding a panic to one of our handlers. Update the echo handler in main.go:

func echo(w http.ResponseWriter, r *http.Request) {
    var payload EchoPayload

    panic("I am panicking")  // Add this line to test panic recovery

    err := readBody(r, &payload)
    if err != nil {
        w.WriteHeader(http.StatusInternalServerError)
        w.Write([]byte(err.Error()))
        return
    }

    w.Write([]byte(fmt.Sprintf("You said '%s'", payload.Message)))
}

Add panic recovery to your middleware stack (it should be first to catch panics from other middleware):

func setupRoutes(s *Server) {
    s.Router.Use(PanicRecoveryMiddleware)
    s.Router.Use(RequestLoggingMiddleware)
    s.Router.Use(ResponseLoggingMiddleware)
    s.Router.Use(TimingMiddleware)
    s.Router.POST("/echo", echo)
    s.Router.GET("/users/:id", getUsers)
    s.Router.POST("/users", createUser)
}

Test the panic recovery:

curl -X POST http://localhost:3000/echo -H "Content-Type: application/json" -d '{"message":"test"}'

You should see:

Client receives: {"error": "Internal server error"}
Server logs: Detailed panic information with stack trace
Server keeps running instead of crashing!

Understanding Middleware Order

The order of middleware matters! They form a chain:

Request → Panic Recovery → Request Logging → Response Logging → Timing → Handler
                ↓              ↓                ↓              ↓
Response ← Panic Recovery ← Request Logging ← Response Logging ← Timing ← Handler

Best practices for middleware order:

Panic Recovery - First, to catch panics from all other middleware
Logging - Early, to log all requests (even ones that error)
Authentication - Before business logic
Business Logic Handlers - Last

What We've Accomplished

We now have:

✅ Request Logging (see what requests come in)
✅ Response Logging (see what responses go out)
✅ Timing Middleware (performance monitoring)
✅ Panic Recovery (graceful error handling)
✅ Middleware Chain (composable, reusable middleware)
✅ Custom ResponseWriter (intercepting response data)
✅ Production-Ready Error Handling (no server crashes)

Testing the Complete Middleware Stack

Remove the panic from the echo handler and test everything:

func echo(w http.ResponseWriter, r *http.Request) {
    var payload EchoPayload

    // Remove or comment out: panic("I am panicking")

    err := readBody(r, &payload)
    if err != nil {
        w.WriteHeader(http.StatusInternalServerError)
        w.Write([]byte(err.Error()))
        return
    }

    w.Write([]byte(fmt.Sprintf("You said '%s'", payload.Message)))
}

Test various endpoints:

# Test echo
curl -X POST http://localhost:3000/echo -H "Content-Type: application/json" -d '{"message":"Hello middleware!"}'

# Test user creation
curl -X POST http://localhost:3000/users -H "Content-Type: application/json" -d '{"name":"Alice","email":"alice@test.com"}'

# Test user retrieval
curl http://localhost:3000/users/1

# Test 404
curl http://localhost:3000/nonexistent

You should see comprehensive logging for every request:

2024/09/14 15:35:10 POST /echo
2024/09/14 15:35:10 POST /echo - Status: 200, Body: You said 'Hello middleware!'
2024/09/14 15:35:10 Request took 0.000045 seconds

Comparing to Real Frameworks

Our Approach:

s.Router.Use(RequestLoggingMiddleware)
s.Router.Use(TimingMiddleware)
s.Router.GET("/users/:id", getUsers)

Gin Framework:

r.Use(gin.Logger())
r.Use(gin.Recovery())
r.GET("/users/:id", getUsers)

Echo Framework:

e.Use(middleware.Logger())
e.Use(middleware.Recover())
e.GET("/users/:id", getUsers)

The concepts are identical! We've built the same middleware system that production frameworks use.

What We've Accomplished in This Series

Across all 7 chapters, we've built a complete web server from scratch:

✅ Foundation (Chapters 1-2)

HTTP server that listens for requests
Basic routing with switch statements

✅ Architecture (Chapters 3-4)

Custom router with clean separation of concerns
Dynamic routing with URL parameters

✅ API Features (Chapters 5-6)

Query parameter handling
JSON request/response processing
CRUD operations with data persistence

✅ Production Readiness (Chapter 7)

Comprehensive logging
Error recovery and graceful error handling
Performance monitoring
Middleware architecture

Final Thoughts

You now understand exactly what happens when your frontend calls an API:

Request hits the server (Chapter 1)
Router matches the path (Chapters 3-4)
Middleware processes the request (Chapter 7)
Handler parses data and does business logic (Chapters 5-6)
Middleware processes the response (Chapter 7)
Response returns to the client

This is the same flow in Express, Gin, Django, Rails, or any web framework - the abstractions are different, but the fundamentals are identical.

Final Challenge: Try building additional middleware for:

CORS handling (for frontend applications)
Rate limiting (prevent abuse)
Authentication (protect certain routes)
Request ID tracking (trace requests across services)

You now have all the tools to build production-ready web servers from first principles!

Series Complete! 🎉

You've built a complete web server with routing, JSON APIs, and production-ready middleware. The concepts you've learned apply to any web framework or language - you now understand the fundamentals beneath all web development. Let me know in the comments if this really helped you.

Building Web Servers from First Principles (Part 6)

Boluwatife Adewusi — Wed, 17 Sep 2025 23:25:21 +0000

In Chapter 5, we learned to handle query parameters for GET requests. But real APIs need to handle POST requests with JSON data, create new resources, and provide proper JSON responses.

Today, we'll build a proper JSON API that can read request bodies, create new data, and respond with structured JSON - just like the APIs your frontend applications expect.

What We've Built So Far

From previous chapters:

✅ Dynamic routing with URL parameters
✅ Query parameter handling for GET requests
✅ Basic JSON responses for data retrieval
❌ POST request body handling
❌ Creating new resources (CRUD operations)
❌ Proper JSON API structure

The Problem: Frontend Apps Need Full CRUD

When building real applications, your frontend needs to:

// GET - Read data (we have this)
const user = await fetch('/users/123').then((r) => r.json());

// POST - Create data (we need this)
const newUser = await fetch('/users', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'John', email: 'john@example.com' }),
}).then((r) => r.json());

Our current server can only handle the first case. Let's fix that.

Understanding Request Bodies

When your frontend sends a POST request with JSON data:

fetch('/users', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'Alice', email: 'alice@example.com' }),
});

The server needs to:

Read the request body (the JSON string)
Parse the JSON into Go structs
Process the data (validate, save, etc.)
Return a proper response

Starting with a Simple Echo Handler

Let's begin by creating a handler that reads JSON from the request body and echoes it back. This will teach us the fundamentals of request body handling.

First, let's set up our data structure. We already have our data.go file with users, so let's start with a simple echo endpoint.

Update main.go:

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
)

func main() {
    server := NewServer(":3000")
    setupRoutes(server)

    server.Start()
}

func setupRoutes(s *Server) {
    s.Router.POST("/echo", echo)
}

type EchoPayload struct {
    Message string `json:"message"`
}

func echo(w http.ResponseWriter, r *http.Request) {
    // Read the request body
    body, err := io.ReadAll(r.Body)
    if err != nil {
        w.WriteHeader(http.StatusInternalServerError)
        w.Write([]byte("Error reading request body"))
        return
    }
    defer r.Body.Close()

    // Parse JSON into our struct
    var payload EchoPayload
    err = json.Unmarshal(body, &payload)
    if err != nil {
        w.WriteHeader(http.StatusBadRequest)
        w.Write([]byte("Invalid JSON"))
        return
    }

    // Echo back the message
    response := fmt.Sprintf("You said '%s'", payload.Message)
    w.Write([]byte(response))
}

Let's test our echo handler:

go run .

In another terminal, test with curl:

curl -X POST http://localhost:3000/echo \
  -H "Content-Type: application/json" \
  -d '{"message": "Hello from frontend!"}'

# Expected: You said 'Hello from frontend!'

What's happening here?

io.ReadAll(r.Body): Reads the entire request body into memory
json.Unmarshal(body, &payload): Parses JSON string into our Go struct
defer r.Body.Close(): Ensures the request body is properly closed
Struct tags: json:"message" tells Go how to map JSON fields to struct fields

Creating a Reusable Body Reading Function

Reading request bodies will be common, so let's extract this into a reusable function:

func readBody(r *http.Request, payload any) error {
    body, err := io.ReadAll(r.Body)
    if err != nil {
        return err
    }
    defer r.Body.Close()

    err = json.Unmarshal(body, payload)
    if err != nil {
        return err
    }

    return nil
}

Now let's simplify our echo handler:

func echo(w http.ResponseWriter, r *http.Request) {
    var payload EchoPayload

    err := readBody(r, &payload)
    if err != nil {
        w.WriteHeader(http.StatusInternalServerError)
        w.Write([]byte(err.Error()))
        return
    }

    w.Write([]byte(fmt.Sprintf("You said '%s'", payload.Message)))
}

Much cleaner! The readBody function handles all the complexity of reading and parsing JSON.

Building a Real CRUD Endpoint: Creating Users

Now let's build something more realistic - a user creation endpoint. Add this to your routes:

func setupRoutes(s *Server) {
    s.Router.POST("/echo", echo)
    s.Router.GET("/users/:id", getUsers)    // We already have this from Chapter 4
    s.Router.POST("/users", createUser)     // NEW: Create users
}

type UserPayload struct {
    Name  string `json:"name"`
    Email string `json:"email"`
}

func createUser(w http.ResponseWriter, r *http.Request) {
    var payload UserPayload

    err := readBody(r, &payload)
    if err != nil {
        w.WriteHeader(http.StatusBadRequest)
        w.Write([]byte("Invalid JSON"))
        return
    }

    // Basic validation
    if payload.Name == "" || payload.Email == "" {
        w.WriteHeader(http.StatusBadRequest)
        w.Write([]byte("Name and email are required"))
        return
    }

    // Create new user (in our in-memory "database")
    newUser := User{
        Id:    len(users) + 1,  // Simple ID generation
        Name:  payload.Name,
        Email: payload.Email,
    }

    // Add to our users slice
    users = append(users, newUser)

    // Return success response
    w.WriteHeader(http.StatusCreated)
    w.Write([]byte("User created successfully!"))
}

Also, don't forget to import the required strconv for the existing getUsers function:

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "strconv"  // Add this
)

Testing Our User Creation API

Let's test creating a new user:

# Create a new user
curl -X POST http://localhost:3000/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice Smith", "email": "alice@example.com"}'

# Expected: User created successfully!

Now let's verify the user was created by fetching it:

# Get the newly created user (should be ID 7, since we have 6 existing users)
curl http://localhost:3000/users/7

# Expected: {"data":{"id":7,"name":"Alice Smith","email":"alice@example.com"}}

Let's test validation:

# Try creating user without required fields
curl -X POST http://localhost:3000/users \
  -H "Content-Type: application/json" \
  -d '{"name": ""}'

# Expected: Name and email are required (400 status)

# Try with invalid JSON
curl -X POST http://localhost:3000/users \
  -H "Content-Type: application/json" \
  -d 'invalid json'

# Expected: Invalid JSON (400 status)

Understanding JSON API Best Practices

Let's improve our API to follow JSON API conventions:

1. Proper Content-Type Headers

func createUser(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json; charset=utf-8")
    // ... rest of function
}

2. Structured JSON Responses

Instead of plain text responses, let's return JSON:

func createUser(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json; charset=utf-8")

    var payload UserPayload
    err := readBody(r, &payload)
    if err != nil {
        w.WriteHeader(http.StatusBadRequest)
        errorResponse := map[string]any{
            "error": "Invalid JSON",
            "message": err.Error(),
        }
        jsonBody, _ := json.Marshal(errorResponse)
        w.Write(jsonBody)
        return
    }

    // Validation
    if payload.Name == "" || payload.Email == "" {
        w.WriteHeader(http.StatusBadRequest)
        errorResponse := map[string]any{
            "error": "Validation failed",
            "message": "Name and email are required",
        }
        jsonBody, _ := json.Marshal(errorResponse)
        w.Write(jsonBody)
        return
    }

    // Create new user
    newUser := User{
        Id:    len(users) + 1,
        Name:  payload.Name,
        Email: payload.Email,
    }
    users = append(users, newUser)

    // Return structured success response
    w.WriteHeader(http.StatusCreated)
    successResponse := map[string]any{
        "message": "User created successfully",
        "data": newUser,
    }
    jsonBody, _ := json.Marshal(successResponse)
    w.Write(jsonBody)
}

Testing Our Improved API

Let's test the improved version:

# Create a user (success case)
curl -X POST http://localhost:3000/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Bob Johnson", "email": "bob@example.com"}'

# Expected: {"data":{"id":8,"name":"Bob Johnson","email":"bob@example.com"},"message":"User created successfully"}

# Test validation (error case)
curl -X POST http://localhost:3000/users \
  -H "Content-Type: application/json" \
  -d '{"name": ""}'

# Expected: {"error":"Validation failed","message":"Name and email are required"}

Understanding HTTP Status Codes

Our API now uses proper HTTP status codes:

200 OK: Successful GET requests
201 Created: Successful POST requests that create resources
400 Bad Request: Client error (invalid JSON, validation failures)
404 Not Found: Resource doesn't exist
500 Internal Server Error: Server error

This is what REST APIs should do - the status code tells the client what happened before they even look at the response body.

What We've Accomplished

We now have:

✅ Request body reading (io.ReadAll, json.Unmarshal)
✅ JSON parsing (into Go structs with tags)
✅ Resource creation (POST endpoints that modify data)
✅ Proper HTTP status codes (200, 201, 400, 404, 500)
✅ Structured JSON responses (consistent error/success format)
✅ Basic validation (required fields, data types)
✅ In-memory persistence (data survives between requests)

Comparing to Real Frameworks

Our Approach:

func createUser(w http.ResponseWriter, r *http.Request) {
    var payload UserPayload
    err := readBody(r, &payload)
    // ... validation and creation
}

Gin Framework:

func createUser(c *gin.Context) {
    var payload UserPayload
    if err := c.ShouldBindJSON(&payload); err != nil {
        c.JSON(400, gin.H{"error": err.Error()})
        return
    }
    // ... validation and creation
}

The concepts are identical - frameworks just provide more convenience methods and features!

What's Next?

In Chapter 7, we'll add middleware to our server - the cross-cutting concerns that real applications need:

Request logging: See what requests are coming in
Response logging: Monitor what data is being sent back
Timing middleware: Track how long requests take
Panic recovery: Gracefully handle server errors

Middleware will make our server more production-ready and easier to debug.

Challenge: Try adding a /users GET endpoint (without the :id parameter) that returns all users. Then create a few users via POST and verify they appear in the list.

Bonus: Add a PUT /users/:id endpoint that can update an existing user's name and email.

Building Web Servers from First Principles (Part 5)

Boluwatife Adewusi — Wed, 17 Sep 2025 23:18:11 +0000

In Chapter 4, we built dynamic routing that could handle URL parameters like /users/:id. But real APIs need more than just path parameters - they need to handle query parameters for filtering, pagination, and user input.

Today, we'll learn how to work with query parameters to build more interactive APIs.

What We've Built So Far

From previous chapters:

✅ Dynamic routing with URL parameters (/users/:id)
✅ Parameter extraction and access
✅ Basic JSON responses
❌ Query parameter handling (?name=John&age=25)
❌ Parameter validation and type conversion

Understanding Query Parameters

When frontend developers make requests like these:

// Search with query parameters
fetch('/search?q=javascript&page=2')

// Greeting with optional name
fetch('/greet?name=John')

// Math operations with parameters  
fetch('/math/add?a=10&b=20')

The server needs to extract and use those query parameters. Unlike URL parameters (:id), query parameters come after the ? and are passed as key-value pairs.

Simple Query Parameter Extraction

Let's start with a basic greeting handler that uses query parameters. Update main.go:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    server := NewServer(":3000")
    setupRoutes(server)

    server.Start()
}

func setupRoutes(s *Server) {
    s.Router.GET("/greet", greet)
}

func greet(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/plain; charset=utf-8")

    name := r.URL.Query().Get("name")

    if name == "" {
        w.Write([]byte("Hello stranger!"))
        return
    }

    w.Write([]byte(fmt.Sprintf("Hello %s", name)))
}

How Query Parameter Access Works:

r.URL.Query() returns all query parameters as a url.Values type
Get("name") extracts the value for the name parameter
If the parameter doesn't exist, Get() returns an empty string

Test this handler:

go run .

curl "http://localhost:3000/greet"
# Returns: Hello stranger!

curl "http://localhost:3000/greet?name=John"
# Returns: Hello John

curl "http://localhost:3000/greet?name=Jane%20Doe"
# Returns: Hello Jane Doe

Notice how URL encoding works - %20 becomes a space.

Multiple Query Parameters

Real APIs often need multiple parameters. Let's create a search handler:

func setupRoutes(s *Server) {
    s.Router.GET("/greet", greet)
    s.Router.GET("/search", search)
}

func search(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/plain; charset=utf-8")

    query := r.URL.Query().Get("q")
    page := r.URL.Query().Get("page")

    w.Write([]byte(fmt.Sprintf("Search results for '%s' (page %s)", query, page)))
}

Test with multiple parameters:

curl "http://localhost:3000/search?q=golang"
# Returns: Search results for 'golang' (page )

curl "http://localhost:3000/search?q=golang&page=3"
# Returns: Search results for 'golang' (page 3)

curl "http://localhost:3000/search?page=2&q=web%20development"
# Returns: Search results for 'web development' (page 2)

Key Insights:

Parameter order in the URL doesn't matter
Missing parameters return empty strings
Empty parameters show as blank in the output

Parameter Type Conversion

Often you need to convert query parameters to specific types and validate them. Let's create a math handler:

func setupRoutes(s *Server) {
    s.Router.GET("/greet", greet)
    s.Router.GET("/search", search)
    s.Router.GET("/math/add", add)
}

func add(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/plain; charset=utf-8")

    a, _ := strconv.ParseInt(r.URL.Query().Get("a"), 0, 0)
    b, _ := strconv.ParseInt(r.URL.Query().Get("b"), 0, 0)

    w.Write([]byte(fmt.Sprintf("%d + %d = %d", a, b, a+b)))
}

Test the math handler with different inputs:

curl "http://localhost:3000/math/add?a=10&b=20"
# Returns: 10 + 20 = 30

curl "http://localhost:3000/math/add?a=100&b=-50"
# Returns: 100 + -50 = 50

curl "http://localhost:3000/math/add?a=hello&b=20"
# Returns: 0 + 20 = 20

curl "http://localhost:3000/math/add?a=10"
# Returns: 10 + 0 = 10

Understanding Different Parameter Types

Let's break down the different ways clients can send data to your API:

1. URL Parameters (Path Parameters)

/users/123        → :id = "123"
/api/v1/users/456 → :version = "v1", :id = "456"

Part of the URL path
Required (URL won't match without them)
Extracted using our GetPathValue() function

2. Query Parameters

/search?q=golang&page=2 → q = "golang", page = "2"

After the ? in the URL
Optional (URL still matches if missing)
Extracted using r.URL.Query().Get()

3. Combined Usage

/users/123/posts?limit=10&sort=date

:id from path = "123"
limit from query = "10"
sort from query = "date"

Common Query Parameter Patterns

Pattern 1: Optional Parameters with Defaults

func listUsers(w http.ResponseWriter, r *http.Request) {
    // Get parameters with defaults
    limitStr := r.URL.Query().Get("limit")
    if limitStr == "" {
        limitStr = "10" // Default limit
    }

    sortBy := r.URL.Query().Get("sort")
    if sortBy == "" {
        sortBy = "name" // Default sort
    }

    // Use the parameters...
}

Pattern 2: Boolean Parameters

func listProducts(w http.ResponseWriter, r *http.Request) {
    // Boolean parameters
    inStock := r.URL.Query().Get("in_stock") == "true"
    onSale := r.URL.Query().Get("on_sale") == "true"

    // Use boolean flags...
}

Pattern 3: Multiple Values for Same Parameter

func filterData(w http.ResponseWriter, r *http.Request) {
    // Get all values for a parameter
    tags := r.URL.Query()["tags"] // []string
    categories := r.URL.Query()["category"] // []string

    // Handle multiple values...
}

Test URL: /filter?tags=web&tags=api&category=tutorial&category=golang

Comparing Our Approach to Frameworks

Our Approach:

func handler(w http.ResponseWriter, r *http.Request) {
    name := r.URL.Query().Get("name")
    id := GetPathValue(r, "id")
}

Gin Framework:

func handler(c *gin.Context) {
    name := c.Query("name")
    id := c.Param("id")
}

Echo Framework:

func handler(c echo.Context) error {
    name := c.QueryParam("name")
    id := c.Param("id")
}

The concepts are identical - frameworks just provide convenience methods!

Current Implementation

Our handlers demonstrate basic query parameter handling with different patterns:

Simple parameter extraction with r.URL.Query().Get()
Multiple parameters in a single handler
Type conversion using strconv.ParseInt()

Testing All Our Handlers

Let's test our complete handler collection:

# Test greeting handler
curl "http://localhost:3000/greet?name=Alice"

# Test search handler  
curl "http://localhost:3000/search?q=golang%20tutorial&page=1"

# Test math handler
curl "http://localhost:3000/math/add?a=15&b=25"

# Test with invalid numbers (they become 0)
curl "http://localhost:3000/math/add?a=not_a_number&b=10"

What We've Accomplished

We now have:

✅ Query parameter extraction (r.URL.Query().Get())
✅ Multiple parameter handling (search with query + page)
✅ Type conversion (strings to integers with strconv.ParseInt())
✅ Basic math operations with URL parameters

What's Next?

In Chapter 6, we'll expand our server capabilities:

Data Persistence: Working with structured data storage
JSON APIs: Creating proper JSON request/response handling
Request Body Processing: Handling POST/PUT requests with JSON data
CRUD Operations: Building a complete API for managing resources

Challenge: Try creating a /calculator endpoint that accepts operation (add, subtract, multiply, divide), a, and b parameters. Handle division by zero and invalid operations!

Bonus: Add support for multiple values: /tags?name=web&name=api&name=tutorial and return all tag names.

Building Web Servers from First Principles (Part 4)

Boluwatife Adewusi — Wed, 17 Sep 2025 23:17:23 +0000

In Chapter 3, we built a clean router that could handle exact path matches. But real APIs need dynamic routes - when your frontend calls /api/users/123, you don't want to pre-register a route for every possible user ID!

Today, we'll implement dynamic routing with URL parameters, just like Express's /users/:id or Gin's /users/:id.

What We've Built So Far

From previous chapters:

✅ Clean HTTP server foundation
✅ Router with method-aware route registration
✅ Exact path matching (/users, /products)
❌ Dynamic paths (/users/:id, /products/:category/:id)

The Problem with Static Routes

Our current router only handles exact matches. For a real user API, you'd need:

// This doesn't scale!
router.GET("/users/1", getUser1Handler)
router.GET("/users/2", getUser2Handler)
router.GET("/users/3", getUser3Handler)
// ... for every possible user ID?

Frontend developers expect to call /users/123, /users/456, or any ID dynamically. We need route patterns like /users/:id.

Starting with a Static Route Problem

Let's follow the notes and start with a static route to see the problem firsthand.

First, let's create some sample data. Create data.go:

package main

type User struct {
    Id    int    `json:"id"`
    Name  string `json:"name"`
    Email string `json:"email"`
}

var users = []User{
    {
        Id:    1,
        Name:  "John Doe",
        Email: "johndoe@gmail.com",
    },
    {
        Id:    2,
        Name:  "Jane Doe",
        Email: "janedoe@gmail.com",
    },
    {
        Id:    3,
        Name:  "Alex Jones",
        Email: "alexjones@gmail.com",
    },
    {
        Id:    4,
        Name:  "Ada Lovelace",
        Email: "adalovelace@gmail.com",
    },
}

Now let's create a handler for a specific user. Update main.go:

package main

import (
    "encoding/json"
    "net/http"
)

func main() {
    server := NewServer(":3000")
    setupRoutes(server)

    server.Start()
}

func setupRoutes(s *Server) {
    // Static route - only works for user ID 1
    s.Router.GET("/users/1", getUser1)
}

func getUser1(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json; charset=utf-8")

    // Hardcoded to return user with ID 1
    var user User
    for _, u := range users {
        if u.Id == 1 {
            user = u
            break
        }
    }

    response := map[string]any{
        "data": user,
    }

    jsonBody, _ := json.Marshal(response)
    w.WriteHeader(http.StatusOK)
    w.Write(jsonBody)
}

Test this static approach:

go run .

curl http://localhost:3000/users/1
# Works: Returns John Doe

curl http://localhost:3000/users/2
# 404: route not found

curl http://localhost:3000/users/123
# 404: route not found

The Problem: We can only handle user ID 1. Every other ID returns 404, even though we have data for users 2, 3, and 4.

Implementing Pattern Matching First

Now let's solve this step by step. First, we'll implement pattern matching to recognize /users/:id routes.

Update the resolveRoute method in router.go:

func (r *Router) resolveRoute(req *http.Request) (HandlerFunc, error) {
    method := req.Method
    path := req.URL.Path

    log.Printf("%s %s", method, path)

    methodRoutes, ok := r.routes[method]
    if !ok {
        return nil, fmt.Errorf("method not supported")
    }

    // Try exact match first
    if handler, ok := methodRoutes[path]; ok {
        return handler, nil
    }

    // If no exact match, try pattern matching
    pathSegments := strings.Split(strings.Trim(path, "/"), "/")

    for routePattern, handler := range methodRoutes {
        routeSegments := strings.Split(strings.Trim(routePattern, "/"), "/")

        if len(pathSegments) == len(routeSegments) && matchesPattern(pathSegments, routeSegments) {
            return handler, nil
        }
    }

    return nil, fmt.Errorf("path does not exist")
}

Add the required imports at the top of router.go:

import (
    "fmt"
    "log"
    "net/http"
    "strings"  // Add this
)

Now we need the pattern matching function:

func matchesPattern(pathSegments, routeSegments []string) bool {
    for i, segment := range routeSegments {
        if strings.HasPrefix(segment, ":") {
            // This is a parameter segment - always matches
            continue
        }
        if segment != pathSegments[i] {
            return false
        }
    }
    return true
}

Understanding the Pattern Matching Loop in Detail

Let me break down that crucial pattern matching loop that we just added:

for routePattern, handler := range methodRoutes {
    routeSegments := strings.Split(strings.Trim(routePattern, "/"), "/")

    if len(pathSegments) == len(routeSegments) &&
       matchesPattern(pathSegments, routeSegments) {
        return handler, nil
    }
}

This loop is doing several important things. Let's trace through an example where:

Request: /users/123
Registered routes: /users/:id, /products/:id, /hello

Step 1: Iterate Through All Registered Routes

for routePattern, handler := range methodRoutes {

The methodRoutes map contains all routes registered for this HTTP method (GET, POST, etc.). For our example:

methodRoutes = {
    "/users/:id":    getUserHandler,
    "/products/:id": getProductHandler,
    "/hello":        helloHandler
}

So our loop will check each of these patterns one by one:

Iteration 1: routePattern = "/users/:id", handler = getUserHandler
Iteration 2: routePattern = "/products/:id", handler = getProductHandler
Iteration 3: routePattern = "/hello", handler = helloHandler

Step 2: Split the Route Pattern into Segments

routeSegments := strings.Split(strings.Trim(routePattern, "/"), "/")

This line is doing two operations:

strings.Trim(routePattern, "/"): Removes leading/trailing slashes

/users/:id becomes users/:id
This handles cases like users/:id or /users/:id/ consistently

strings.Split(..., "/"): Splits on forward slashes to get individual path segments

Let's see this in action for each iteration:

Iteration 1 (routePattern = "/users/:id"):

strings.Trim("/users/:id", "/")     // → "users/:id"
strings.Split("users/:id", "/")     // → ["users", ":id"]
// So: routeSegments = ["users", ":id"]

Iteration 2 (routePattern = "/products/:id"):

strings.Trim("/products/:id", "/")  // → "products/:id"
strings.Split("products/:id", "/")  // → ["products", ":id"]
// So: routeSegments = ["products", ":id"]

Iteration 3 (routePattern = "/hello"):

strings.Trim("/hello", "/")         // → "hello"
strings.Split("hello", "/")         // → ["hello"]
// So: routeSegments = ["hello"]

Remember, we already split the incoming request path earlier:

pathSegments := strings.Split(strings.Trim(path, "/"), "/")
// For "/users/123" this gives us: ["users", "123"]

Step 3: Check Length and Pattern Match

if len(pathSegments) == len(routeSegments) &&
   matchesPattern(pathSegments, routeSegments) {
    return handler, nil
}

This condition has two parts that BOTH must be true:

Part 1: Length Check (len(pathSegments) == len(routeSegments))

This ensures the number of segments match. For our request /users/123 (2 segments):

Iteration 1: len(["users", "123"]) == len(["users", ":id"]) → 2 == 2 ✅
Iteration 2: len(["users", "123"]) == len(["products", ":id"]) → 2 == 2 ✅
Iteration 3: len(["users", "123"]) == len(["hello"]) → 2 == 1 ❌

The length check immediately eliminates routes that can't possibly match.

Part 2: Pattern Match (matchesPattern(pathSegments, routeSegments))

This is where the actual pattern matching logic happens. The function compares each segment:

For the iterations that passed the length check:

Iteration 1: matchesPattern(["users", "123"], ["users", ":id"])

i=0: segment = "users" (doesn't start with :)
- Check: "users" != "users"? NO → Continue
i=1: segment = ":id" (starts with :)
- This is a parameter → continue (always matches)
Result: true ✅

Iteration 2: matchesPattern(["users", "123"], ["products", ":id"])

i=0: segment = "products" (doesn't start with :)
- Check: "products" != "users"? YES → return false
Result: false ❌

So for /users/123:

Route /users/:id matches! (length ✅ + pattern ✅)
Route /products/:id doesn't match (length ✅ + pattern ❌)
Route /hello doesn't match (length ❌)

The loop returns the handler for /users/:id.

Why This Design Works

This approach is elegant because:

Fast Length Check: Eliminates impossible matches immediately
Flexible Parameters: :id matches any value (123, abc, anything)
Exact Matching: Non-parameter segments must match exactly
First Match Wins: Returns as soon as a pattern matches

Now let's update our route registration to use a pattern. Update main.go:

func setupRoutes(s *Server) {
    // Dynamic route pattern - but handler still doesn't know the ID
    s.Router.GET("/users/:id", getUsers)
}

func getUsers(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json; charset=utf-8")

    // We can match the pattern but can't access the ID yet!
    // For now, let's just return the first user
    user := users[0]

    response := map[string]any{
        "data": user,
        "note": "Pattern matching works, but we can't access the ID parameter yet!",
    }

    jsonBody, _ := json.Marshal(response)
    w.WriteHeader(http.StatusOK)
    w.Write(jsonBody)
}

Test the pattern matching:

go run .

curl http://localhost:3000/users/1
curl http://localhost:3000/users/2
curl http://localhost:3000/users/123
curl http://localhost:3000/users/anything

All of these now return a response! The pattern matching is working - /users/:id matches any /users/something request. But notice we're always returning the same user because we can't access the ID parameter yet.

The Current Problem: We Can't Extract URL Values

Our pattern matching works, but we have a new problem: how do we access the actual ID that was requested? The handler needs to know whether the user requested /users/1 or /users/123.

This is exactly what we need to solve next - extracting parameter values from the URL.

Implementing Parameter Extraction

Now let's extend our router to extract the parameter values and make them available to handlers.

First, we need to modify our resolveRoute method to extract parameters and store them:

func (r *Router) resolveRoute(req *http.Request) (HandlerFunc, error) {
    method := req.Method
    path := req.URL.Path

    log.Printf("%s %s", method, path)

    methodRoutes, ok := r.routes[method]
    if !ok {
        return nil, fmt.Errorf("method not supported")
    }

    // Try exact match first
    if handler, ok := methodRoutes[path]; ok {
        return handler, nil
    }

    // If no exact match, try pattern matching
    pathSegments := strings.Split(strings.Trim(path, "/"), "/")

    for routePattern, handler := range methodRoutes {
        routeSegments := strings.Split(strings.Trim(routePattern, "/"), "/")

        if len(pathSegments) == len(routeSegments) && matchesPattern(pathSegments, routeSegments) {
            // NEW: Extract parameters and add to request context
            params := extractParams(pathSegments, routeSegments)
            if len(params) > 0 {
                ctx := context.WithValue(req.Context(), "params", params)
                *req = *req.WithContext(ctx)
            }
            return handler, nil
        }
    }

    return nil, fmt.Errorf("path does not exist")
}

Add the context import:

import (
    "context"  // Add this
    "fmt"
    "log"
    "net/http"
    "strings"
)

Now let's add the parameter extraction function:

func extractParams(pathSegments, routeSegments []string) map[string]string {
    params := make(map[string]string)
    for i, segment := range routeSegments {
        if strings.HasPrefix(segment, ":") {
            paramName := segment[1:] // Remove the ":"
            params[paramName] = pathSegments[i]
        }
    }
    return params
}

How Parameter Extraction Works:

For /users/:id matching /users/123:

routeSegments = ["users", ":id"]
pathSegments = ["users", "123"]
When we see :id at position 1, we extract pathSegments[1] which is "123"
Result: {"id": "123"}

Adding a Helper Function to Access Parameters

We need a way for handlers to access the extracted parameters:

// Helper function to get path parameters from request context
func GetPathValue(r *http.Request, key string) string {
    if params, ok := r.Context().Value("params").(map[string]string); ok {
        return params[key]
    }
    return ""
}

Updating the Handler to Use Parameters

Now let's update our handler to actually use the extracted ID parameter:

func getUsers(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json; charset=utf-8")

    // NOW we can access the ID parameter from the URL!
    userIdStr := GetPathValue(r, "id")
    userId, err := strconv.ParseInt(userIdStr, 10, 32)
    if err != nil {
        w.WriteHeader(http.StatusBadRequest)
        response := map[string]any{
            "error": "Invalid user ID",
        }
        jsonBody, _ := json.Marshal(response)
        w.Write(jsonBody)
        return
    }

    // Find the user with this ID
    var user User
    for _, u := range users {
        if u.Id == int(userId) {
            user = u
            break
        }
    }

    if user.Id == 0 {
        w.WriteHeader(http.StatusNotFound)
        response := map[string]any{
            "error": "user not found",
        }
        jsonBody, _ := json.Marshal(response)
        w.Write(jsonBody)
        return
    }

    response := map[string]any{
        "data": user,
    }

    jsonBody, _ := json.Marshal(response)
    w.WriteHeader(http.StatusOK)
    w.Write(jsonBody)
}

Add the import for strconv:

import (
    "encoding/json"
    "net/http"
    "strconv"  // Add this
)

Testing the Complete Solution

Now let's test our complete dynamic routing solution:

go run .

Try different user IDs:

curl http://localhost:3000/users/1
# Returns: {"data":{"id":1,"name":"John Doe","email":"johndoe@gmail.com"}}

curl http://localhost:3000/users/2
# Returns: {"data":{"id":2,"name":"Jane Doe","email":"janedoe@gmail.com"}}

curl http://localhost:3000/users/4
# Returns: {"data":{"id":4,"name":"Ada Lovelace","email":"adalovelace@gmail.com"}}

curl http://localhost:3000/users/999
# Returns: {"error":"user not found"}

curl http://localhost:3000/users/abc
# Returns: {"error":"Invalid user ID"}

Perfect! Our router now:

✅ Matches patterns like /users/:id
✅ Extracts parameters from the URL
✅ Makes parameters accessible to handlers
✅ Handles different user IDs dynamically
✅ Provides proper error handling for invalid/missing data

What We've Accomplished

We now have:

✅ Dynamic route patterns (/users/:id)
✅ Pattern matching (recognizes parameterized routes)
✅ Parameter extraction (gets values from URLs)
✅ Parameter access (GetPathValue(r, "id"))
✅ Flexible routing (works with any ID)
✅ Proper error handling (invalid IDs, missing users)
✅ JSON responses (real API behavior)

What's Next?

In Chapter 5, we'll focus getting data from the request. Right now, our only source of information from the request is the url but there are multiple ways the client can pass data to our web server

Challenge: Try creating a route pattern like /products/:category/:id and a handler that uses both parameters. See how the pattern matching handles nested parameters!

Next: Chapter 5: Query Params

Building Web Servers from First Principles (Part 3)

Boluwatife Adewusi — Wed, 17 Sep 2025 23:15:42 +0000

In Chapter 2, we built routing with nested switch statements. It worked, but imagine explaining that approach to a frontend developer: "Just add more nested switch cases for every new endpoint." They'd think we were crazy!

Today, we'll solve this by building a proper router - a separate component that handles all the routing logic, just like Express.js does with app.get() and app.post().

What We've Built So Far

From the previous chapters, we have:

✅ A basic HTTP server that listens for requests
✅ Path-based routing using switch statements
❌ Nested switch statements that are hard to maintain
❌ No clean way to register routes dynamically

The Problem with Our Current Approach

Let's first look at where our nested switch approach leads us. Here's what our ServeHTTP method looks like when extended with proper HTTP method support:

func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    path := r.URL.Path
    log.Printf("%s %s", r.Method, path)
    w.Header().Set("Content-Type", "text/plain; charset=utf-8")
    w.WriteHeader(http.StatusOK)

    switch r.Method {
    case http.MethodGet:
        GET(path, w)
    case http.MethodPost:
        POST(path, w)
    default:
        not_Supported(w)
    }
}

func GET(path string, w http.ResponseWriter) {
    switch path {
    case "/hello":
        hello(w)
    case "/goodbye":
        goodbye(w)
    case "/time":
        getTime(w)
    default:
        welcome(w)
    }
}

func POST(path string, w http.ResponseWriter) {
    switch path {
    case "/hello":
        post_hello(w)
    case "/messages":
        messages(w)
    case "/time":
        post_getTime(w)
    default:
        post_welcome(w)
    }
}

This approach has several problems:

Scattered Logic: Route definitions are spread across multiple functions
Hard to Extend: Adding new HTTP methods requires new functions
No Dynamic Registration: You can't programmatically add routes
Poor Organization: Unlike app.get('/users', handler) in Express

Understanding What Frameworks Do

When you use Express.js, you write:

app.get('/users', getUsersHandler)
app.post('/users', createUserHandler)  
app.put('/users/:id', updateUserHandler)

Or with Gin in Go:

r.GET("/users", getUsersHandler)
r.POST("/users", createUserHandler)
r.PUT("/users/:id", updateUserHandler)

What's happening under the hood? The framework stores these routes in a data structure and matches incoming requests against them. Let's build our own version.

Designing Our Router

We need a router that can:

Register routes with method + path + handler
Match incoming requests to the right handler
Execute the matched handler or return 404

Let's start by designing the data structure. We need to store routes by HTTP method and path:

routes = {
    "GET": {
        "/hello": helloHandler,
        "/users": getUsersHandler
    },
    "POST": {  
        "/users": createUserHandler,
        "/messages": messagesHandler
    }
}

Building the Router Component

Create a new file router.go:

package main

import (
    "fmt"
    "log"
    "net/http"
)

type HandlerFunc func(w http.ResponseWriter, r *http.Request)

type Router struct {
    routes map[string]map[string]HandlerFunc
}

func NewRouter() *Router {
    return &Router{
        routes: make(map[string]map[string]HandlerFunc),
    }
}

Key Design Decisions:

HandlerFunc type: This matches the signature that handlers need - access to both response and request
Nested maps: map[method]map[path]handler gives us fast O(1) lookup
Pointer receiver: We'll modify the router's state when adding routes

Adding Route Registration Methods

Now let's add the methods that let us register routes (like Express's app.get()):

func (r *Router) addRoute(method string, path string, handler HandlerFunc) {
    if r.routes[method] == nil {
        r.routes[method] = make(map[string]HandlerFunc)
    }

    r.routes[method][path] = handler
}

func (r *Router) GET(path string, handler HandlerFunc) {
    r.addRoute(http.MethodGet, path, handler)
}

func (r *Router) POST(path string, handler HandlerFunc) {
    r.addRoute(http.MethodPost, path, handler)
}

func (r *Router) PUT(path string, handler HandlerFunc) {
    r.addRoute(http.MethodPut, path, handler)
}

func (r *Router) PATCH(path string, handler HandlerFunc) {
    r.addRoute(http.MethodPatch, path, handler)
}

func (r *Router) DELETE(path string, handler HandlerFunc) {
    r.addRoute(http.MethodDelete, path, handler)
}

Now we can register routes just like in frameworks:

router.GET("/hello", helloHandler)
router.POST("/users", createUserHandler)

Implementing Route Resolution

The router needs to match incoming requests to handlers:

func (r *Router) resolveRoute(req *http.Request) (HandlerFunc, error) {
    method := req.Method
    path := req.URL.Path

    log.Printf("%s %s", method, path)

    methodRoutes, ok := r.routes[method]
    if !ok {
        return nil, fmt.Errorf("method not supported")
    }

    handler, ok := methodRoutes[path]
    if !ok {
        return nil, fmt.Errorf("path does not exist")
    }

    return handler, nil
}

Making the Router Handle HTTP Requests

Our router needs to implement the http.Handler interface so it can handle requests:

func (r *Router) ServeHTTP(w http.ResponseWriter, req *http.Request) {
    handler, err := r.resolveRoute(req)

    if err != nil {
        w.WriteHeader(http.StatusNotFound)
        w.Write([]byte("route not found"))
        return
    }

    handler(w, req)
}

This is beautiful - our router finds the right handler and calls it, or returns 404 if no match is found.

Updating Our Server to Use the Router

Now we need to integrate the router into our server. Update server.go:

package main

import (
    "log"
    "net/http"
)

type Server struct {
    Addr   string
    Router *Router
    server *http.Server
}

func NewServer(addr string) *Server {
    router := NewRouter()

    server := &Server{
        Addr:   addr,
        Router: router,
    }

    return server
}

func (s *Server) Start() {
    s.server = &http.Server{
        Addr:    s.Addr,
        Handler: s,
    }
    log.Println("Server starting at", s.Addr)
    err := s.server.ListenAndServe()
    if err != nil {
        log.Fatal(err)
    }
}

func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    s.Router.ServeHTTP(w, r)
}

What changed?

Server now has a Router field
NewServer creates a router instance
ServeHTTP delegates to the router instead of handling routing itself

Creating Handler Functions

We need to update our handler functions to match our new HandlerFunc signature:

func welcome(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("Welcome to our Go Webserver!"))
}

func hello(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("Hello, World!"))
}

func goodbye(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("Goodbye, see you later!"))
}

func getTime(w http.ResponseWriter, r *http.Request) {
    message := fmt.Sprintf("Current Time: %s", time.Now().Format("2006-01-02 15:04:05"))
    w.Write([]byte(message))
}

func post_hello(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("Hello via POST!"))
}

func messages(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("You posted a new message"))
}

func post_getTime(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("POST request received on /time"))
}

func post_welcome(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("Welcome to our Go Webserver from POST!"))
}

Note: We added the *http.Request parameter to each handler. Now our handlers have access to the full request information.

Registering Routes

Update main.go to register our routes using the new router API:

package main

import (
    "fmt"
    "net/http"
    "time"
)

func main() {
    server := NewServer(":3000")
    setupRoutes(server)

    server.Start()
}

func setupRoutes(s *Server) {
    s.Router.GET("/", welcome)
    s.Router.GET("/hello", hello)
    s.Router.GET("/goodbye", goodbye)
    s.Router.GET("/time", getTime)
    s.Router.POST("/", post_welcome)
    s.Router.POST("/hello", post_hello)
    s.Router.POST("/messages", messages)
    s.Router.POST("/time", post_getTime)
}

Look how clean this is! It reads just like Express or Gin route definitions.

Testing Our New Router

Let's test our router-based server:

go run .

Test different routes and methods:

# GET routes
curl http://localhost:3000/
curl http://localhost:3000/hello
curl http://localhost:3000/goodbye  
curl http://localhost:3000/time

# POST routes
curl -X POST http://localhost:3000/
curl -X POST http://localhost:3000/hello
curl -X POST http://localhost:3000/messages

# Test 404s
curl http://localhost:3000/nonexistent
curl -X DELETE http://localhost:3000/hello

Expected behavior:

GET and POST routes work as expected
Unknown paths return "route not found"
Unsupported methods return "route not found"

What We've Accomplished

We now have:

✅ Clean route registration (like Express/Gin)
✅ Separation of concerns (routing logic separated from server logic)
✅ HTTP method awareness (GET vs POST behave differently)
✅ Proper error handling (404 for unknown routes)
✅ Scalable architecture (easy to add new routes)

Current Limitations

Our router is much better, but still has some limitations:

1. No Dynamic Routes

We can't handle /users/123 or /products/456 - each route must be exactly defined.

2. No Middleware Support

Real APIs need logging, authentication, CORS, etc. We have no way to add these cross-cutting concerns.

3. Basic Error Responses

Our 404 response is just plain text - real APIs return JSON error responses.

What's Next?

In Chapter 4, we'll tackle the biggest limitation - dynamic routes. We'll enable routes like /users/:id and /products/:category/:id, and learn how to extract those parameters in our handlers.

This will bring us much closer to production-ready routing that can handle real API requirements.

Challenge: Try adding some new routes using different HTTP methods. Add a DELETE route for /users and a PUT route for /messages. See how easy it is now compared to our switch statement approach!

Building Web Servers from First Principles (Part 2)

Boluwatife Adewusi — Wed, 17 Sep 2025 23:12:44 +0000

In Chapter 1, we built a server that responded with "hello world" to every request. That's like having an API that returns the same response whether your frontend calls /api/users, /api/products, or /api/login. Not very useful!

Today, we'll fix this by making our server route-aware - different paths will return different responses, just like a real API.

What We've Built So Far

From Chapter 1, we have a basic server that:

✅ Listens on port 3000
✅ Responds to HTTP requests
❌ Returns the same response for every path

The Problem Frontend Developers Face

When you write JavaScript like this:

// Different endpoints, different data expected
const users = await fetch('/api/users').then(r => r.json())
const products = await fetch('/api/products').then(r => r.json())  
const profile = await fetch('/api/profile').then(r => r.json())

You expect different responses from each endpoint. Our current server can't handle this - it would return "hello world" for all three calls.

Inspecting the Request Path

The solution starts with examining what the client is actually requesting. Let's modify our ServeHTTP method to look at the request path:

func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    path := r.URL.Path
    log.Printf("%s %s", r.Method, path)

    // For now, let's just echo back what was requested
    message := fmt.Sprintf("You requested: %s", path)
    w.WriteHeader(http.StatusOK)
    w.Write([]byte(message))
}

Let's test this incremental change:

go run .

In another terminal, try different paths:

curl http://localhost:3000/users
curl http://localhost:3000/products  
curl http://localhost:3000/api/login

Expected Responses:

You requested: /users
You requested: /products
You requested: /api/login

Great! Now our server knows what path was requested. But we still need to return different content for different paths.

Building Route Logic with Switch Statements

Here's where most tutorials jump straight to a routing library. But let's first understand why those libraries exist by building routing logic ourselves.

The most straightforward approach is a switch statement:

func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    path := r.URL.Path
    log.Printf("%s %s", r.Method, path)

    w.Header().Set("Content-Type", "text/plain; charset=utf-8")
    w.WriteHeader(http.StatusOK)

    switch path {
    case "/hello":
        hello(w)
    case "/goodbye":
        goodbye(w)  
    case "/time":
        getTime(w)
    default:
        welcome(w)
    }
}

Now we need to create those handler functions. Let's add them to our server.go:

func welcome(w http.ResponseWriter) {
    w.Write([]byte("Welcome to our Go Webserver!"))
}

func hello(w http.ResponseWriter) {
    w.Write([]byte("Hello, World!"))
}

func goodbye(w http.ResponseWriter) {
    w.Write([]byte("Goodbye, see you later!"))
}

func getTime(w http.ResponseWriter) {
    message := fmt.Sprintf("Current Time: %s", time.Now().Format("2006-01-02 15:04:05"))
    w.Write([]byte(message))
}

Don't forget to import the time package at the top of your file:

import (
    "fmt"
    "log"
    "net/http"
    "time"  // Add this line
)

Testing Our Route-Aware Server

Let's test our newly route-aware server:

go run .

Try these different endpoints:

curl http://localhost:3000/hello
curl http://localhost:3000/goodbye
curl http://localhost:3000/time
curl http://localhost:3000/
curl http://localhost:3000/unknown-path

Expected Responses:

Hello, World!
Goodbye, see you later!
Current Time: 2024-09-14 15:30:45
Welcome to our Go Webserver!
Welcome to our Go Webserver!

Perfect! Our server now behaves like a real API - different paths return different responses.

What We've Accomplished

We now have:

✅ Path-aware routing (different responses for different URLs)
✅ Clean handler separation (each route has its own function)
✅ Default route handling (catch-all for unknown paths)
✅ Request logging (see what's being requested)

The Problems We're Creating

While our switch statement approach works, it's already showing some issues that will become painful as we scale:

1. Method Blindness

Our server doesn't distinguish between HTTP methods. Try this:

curl -X POST http://localhost:3000/hello
curl -X DELETE http://localhost:3000/hello  
curl -X PUT http://localhost:3000/hello

All return the same response! In a real API, GET /users and POST /users should do very different things.

2. Growing Switch Statement

Imagine adding 20 more routes:

switch path {
case "/hello":
    hello(w)
case "/goodbye": 
    goodbye(w)
case "/time":
    getTime(w)
case "/users":
    getUsers(w)
case "/products":
    getProducts(w) 
case "/orders":
    getOrders(w)
// ... 15 more cases
default:
    welcome(w)
}

This becomes unwieldy quickly - like having one massive if-else chain in your frontend code.

3. No Dynamic Paths

What if your frontend needs to call /users/123 or /products/456? We'd need a case for every possible ID, which is impossible.

4. Handler Signatures

Our handler functions only take a ResponseWriter. Real APIs need access to the full Request to read query parameters, headers, and request bodies.

Quick Fix: Adding HTTP Method Support

Before we move on, let's quickly add basic HTTP method support to see how the complexity grows:

func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    path := r.URL.Path
    method := r.Method
    log.Printf("%s %s", method, path)

    w.Header().Set("Content-Type", "text/plain; charset=utf-8")
    w.WriteHeader(http.StatusOK)

    // Now we need to check BOTH path AND method
    switch method {
    case "GET":
        s.handleGET(w, r, path)
    case "POST": 
        s.handlePOST(w, r, path)
    default:
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
    }
}

func (s *Server) handleGET(w http.ResponseWriter, r *http.Request, path string) {
    switch path {
    case "/hello":
        hello(w)
    case "/goodbye":
        goodbye(w)
    case "/time":
        getTime(w)
    default:
        welcome(w)
    }
}

func (s *Server) handlePOST(w http.ResponseWriter, r *http.Request, path string) {
    switch path {
    case "/hello":
        w.Write([]byte("Hello via POST!"))
    default:
        http.Error(w, "Not found", http.StatusNotFound)
    }
}

Test the different methods:

curl -X GET http://localhost:3000/hello   # Returns: Hello, World!
curl -X POST http://localhost:3000/hello  # Returns: Hello via POST!
curl -X PUT http://localhost:3000/hello   # Returns: Method not allowed

See how quickly this is getting complex? We're already at nested switch statements, and we only have a few routes!

What's Next?

In Chapter 3, we'll solve these growing pains by building a proper router - a separate component responsible for matching paths and methods to handlers. This will give us:

Clean separation of concerns (routing logic separate from business logic)
Support for different HTTP methods
A foundation for dynamic routes like /users/:id
Better organization as our API grows

Think of it like moving from one giant JavaScript file to a properly structured application with separate modules.

Challenge: Before Chapter 3, try adding a few more routes to see how unwieldy the switch statement becomes. Add routes like /api/users, /api/products, and /api/orders for both GET and POST methods.

Building Web Servers from First Principles (Part 1)

Boluwatife Adewusi — Wed, 17 Sep 2025 23:12:20 +0000

Ever made a fetch() call from JavaScript and wondered what's actually happening on the other end? Or used Gin/Echo/Fiber and typed r.GET("/users", handler) without thinking about what makes that route registration work?

If you're a frontend engineer who's curious about what happens after your API request leaves the browser, or a backend developer who wants to understand what's beneath those convenient framework abstractions, this series is for you.

Who This Series Is For

Frontend Engineers: You know how to make HTTP requests, but what's actually running on that server responding to your POST /api/users calls? We'll build it from scratch.

Backend Developers: You've written gin.GET("/users/:id", getUserHandler), but do you know how that path matching actually works? What happens between the network request hitting your server and your handler function being called?

We're going to build all of this ourselves - no frameworks, just Go's standard library and our own code.

Prerequisites

Go installed: Download from https://golang.org/dl/
curl installed: Most systems have it, or get it from https://curl.se/download.html
Text editor: VS Code, Vim, or any editor you prefer

The Problem We're Solving

When your JavaScript does this:

fetch('/api/users/123', { method: 'GET' })

Or your mobile app makes this call:

URLSession.shared.dataTask(with: url)

Something has to be listening on the other end, parse that HTTP request, figure out what /api/users/123 means, and send back a response. Today, we'll build that "something" from first principles.

Setting Up Our Project

First, let's create our Go module:

mkdir custom-http-server && cd custom-http-server/chap1
go mod init webserver

This creates a go.mod file that manages our dependencies.

The Simplest Possible Server

Let's start with the most basic question: How do we create something that can listen for HTTP requests?

When you use Gin, you write:

r := gin.Default()
r.GET("/", func(c *gin.Context) { c.String(200, "hello world") })
r.Run(":3000")

But what is Gin actually doing under the hood? Let's build our own version to understand.

Go's standard library provides everything we need through the net/http package. But instead of just calling http.ListenAndServe(), let's build our own server struct to understand the underlying concepts.

Create server.go:

package main

import (
    "fmt"
    "log"
    "net/http"
)

type Server struct {
    Addr   string
    server *http.Server
}

Why are we creating a Server struct instead of just using the standard library directly? This gives us:

Encapsulation: All server-related logic stays together (just like Gin's Engine)
Extensibility: We can easily add features like middleware, custom routing, etc.
Testability: We can create multiple server instances for testing

Now let's add a constructor function:

func NewServer(addr string) Server {
    return Server{
        Addr: addr,
    }
}

Implementing the HTTP Handler

Here's where it gets interesting. For our server to handle HTTP requests, it needs to implement the http.Handler interface. This interface has just one method:

ServeHTTP(ResponseWriter, *Request)

This is the method that gets called every time an HTTP request comes in - whether it's your frontend's fetch() call, a mobile app request, or someone testing with curl.

func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusOK)
    w.Write([]byte("hello world"))
}

What's happening here?

w http.ResponseWriter: This is how we send data back to the client (like writing res.json() in Express or c.JSON() in Gin)
r *http.Request: This contains all the information about the incoming request - the path, method, headers, body, everything
w.WriteHeader(): Sets the HTTP status code (200 OK in this case)
w.Write(): Sends the actual response body back to the client

Starting Our Server

Now we need a way to start our server and make it listen for incoming connections:

func (s *Server) Start() {
    s.server = &http.Server{
        Addr:    s.Addr,
        Handler: s,  // This is crucial - we're telling Go to use our ServeHTTP method
    }
    fmt.Println("Server starting at", s.Addr)
    err := s.server.ListenAndServe()
    if err != nil {
        log.Fatal(err)
    }
}

The key insight here is Handler: s - we're passing our entire server struct as the handler. Go will call our ServeHTTP method for every incoming request.

Putting It All Together

Create main.go:

package main

func main() {
    server := NewServer(":3000")
    server.Start()
}

Testing Our Server

Let's see our server in action:

go run .

You should see:

Server starting at :3000

Now let's test it like a frontend developer would. In another terminal:

curl http://localhost:3000

Expected Response:

hello world

Try different paths (like your frontend might request):

curl http://localhost:3000/api/users
curl http://localhost:3000/api/products/123
curl -X POST http://localhost:3000/api/login -d '{"username":"test"}'

What do you notice? Every request returns the same "hello world" response, regardless of the path or HTTP method. This is because our ServeHTTP method doesn't look at the request details yet - it's like having one giant catch-all route handler.

What We've Built So Far

We now have:

✅ A working HTTP server that can receive any HTTP request
✅ Custom server struct for extensibility (foundation for adding features)
✅ Understanding of the http.Handler interface (what frameworks build on top of)
✅ Basic request/response cycle (what happens when your frontend makes a request)

Current Limitations

Our server has the same issues you'd face with one giant route handler in Express:

Single Response: Every request gets the same "hello world" response
No Route Awareness: We ignore the requested path completely (/users vs /products)
No Method Handling: GET, POST, PUT, DELETE all behave the same
No Request Data: We don't read query parameters, headers, or request body

Imagine if every API endpoint in your frontend returned the same response - not very useful!

What's Next?

In Chapter 2, we'll address the first major limitation - handling different routes. We'll modify our ServeHTTP method to inspect the incoming request path and return different responses based on what the client requested.

But here's a preview of what we'll discover: handling routes directly in ServeHTTP quickly becomes unwieldy (like having one massive if-else chain). This will set us up perfectly for Chapter 3, where we'll build a proper routing system - similar to how Express or Gin handles routes.

Try This Challenge: Before moving to Chapter 2, try modifying the ServeHTTP method to print the request path and method to the console. This will help you see exactly what requests are coming in from your tests.

Hint: Use fmt.Printf("Request: %s %s\n", r.Method, r.URL.Path)

Next: Chapter 2: Handling Multiple Routes - The Monolithic Approach

File Organizer, Part 3: Making It Interactive with Cobra! 🐍⚡

Boluwatife Adewusi — Tue, 15 Oct 2024 19:25:51 +0000

Welcome to the third part of our File Organizer journey! So far, we’ve built a tool that organizes files into categories and made it flexible enough for users to modify those categories—without writing code! But what’s the fun in a tool that’s not interactive? Let’s take it up a notch by adding a command-line interface (CLI) so users can interact with it directly! 🎯

How do we do that? Enter Cobra—a powerful library used by tools like Docker and Kubernetes. If you’re ready to make your Go project interactive and shareable, buckle up! 🚀

Step 1: Installing Cobra

First, open your terminal and install Cobra with:

go get -u github.com/spf13/cobra@latest

With that, Cobra is locked and loaded! Now, let’s organize our project structure.

Step 2: Setting Up Project Structure

Create a folder named cmd inside your project directory. This is where we’ll define commands and their handlers. Inside cmd, create two files:

root.go – Defines the CLI commands
handlers.go – Calls the right functions based on the commands

Step 3: Displaying Categories with `handlers.go`

In handlers.go, our first mission is to display the saved categories beautifully using Go's built-in text/tabwriter package. Think of it as adding that little touch of elegance to the terminal output. 💅

// handlers.go

package cmd

import (
    "your-project-path/models"
    "errors"
    "fmt"
    "os"
    "path/filepath"
    "strings"
    "text/tabwriter"
)

var store = models.NewFileDataStore("")

// DisplayCategories lists all categories in a pretty format
func DisplayCategories(verbose bool) {
    categories, err := store.GetCategories()

    if err != nil {
        fmt.Println(err)
    }

    const padding = 3
    w := tabwriter.NewWriter(os.Stdout, 0, 0, padding, ' ', tabwriter.Debug)

    defer w.Flush()

    if verbose {
        _, _ = fmt.Fprintln(w, "Category\t Folder Name\t Extensions\t")
        for _, category := range categories {
            _, _ = fmt.Fprintln(
                w,
                fmt.Sprintf("%s\t %s\t %s\t",
                    category.FileType,
                    category.FolderName,
                    strings.Join(category.Extensions, ","),
                ),
            )
        }
    } else {
        _, _ = fmt.Fprintln(w, "Category\t Folder Name\t")
        for _, category := range categories {
            _, _ = fmt.Fprintln(w, fmt.Sprintf("%s\t %s\t", category.FileType, category.FolderName))
        }
    }
}

Next, we’ll add functions for adding and removing categories to keep things dynamic and easy to manage. 🛠️


func addCategory(fileType, folderName string, extensions []string) {
    if fileType == "" {
        fmt.Println(errors.New("category name not supplied"))
        return
    }

    var extensionsToAdd []string
    var extensionsToRemove []string

    for _, extension := range extensions {
        if strings.HasPrefix(extension, "-") {
            rawExtension := strings.ReplaceAll(extension, "-", "")
            if strings.HasPrefix(rawExtension, ".") {
                extensionsToRemove = append(extensionsToRemove, rawExtension)
            } else {
                extensionsToRemove = append(extensionsToRemove, "."+extension)
            }
        } else {
            if strings.HasPrefix(extension, ".") {
                extensionsToAdd = append(extensionsToAdd, extension)
            } else {
                extensionsToAdd = append(extensionsToAdd, "."+extension)
            }
        }
    }

    err := store.AddCategory(fileType, folderName, extensionsToAdd)

    if err != nil {
        fmt.Println(err)
        return
    }

    err = store.RemoveExtensionsFromCategory(fileType, extensionsToRemove)

    if err != nil {
        fmt.Println(err)
        return
    }

    DisplayCategories(true)
}

func removeCategory(fileType string) {
    err := store.RemoveCategory(fileType)

    if err != nil {
        fmt.Println(err)
    }

    fmt.Println("Successfully removed")
    DisplayCategories(false)
}

func organizeFiles(dir string) {
    files, err := os.ReadDir(dir)

    if err != nil {
        fmt.Println(err)
    }

    for _, file := range files {
        if file.IsDir() {
            continue
        }

        fileName := file.Name()

        category, err := store.GetType(fileName)

        if err != nil {
            fmt.Println(err)
            continue
        }

        err = category.MoveToFolder(filepath.Join(dir, fileName))

        if err != nil {
            fmt.Println(err)
            continue
        }

        fmt.Printf("%s moved to %s\n", fileName, filepath.Join(dir, category.FolderName, fileName))
    }
}

Step 4: Setting Up Commands with `root.go`

Now comes the fun part! Let’s define our interactive commands in root.go. For example, here’s how you can set up the display command:

// root.go

package cmd

import (
    "github.com/spf13/cobra"
)

// RootCmd is the base command
var rootCmd = &cobra.Command{
    Use:     "org",
    Short:   "Org is a file organizer",
    Long:    `Org is a file organizer that categorizes and moves files into folders based on their extensions.`,
    Version: "0.1",
}

// Initialize the CLI commands
func init() {
        categoryListCmd.Flags().BoolVarP(&verbose, "verbose", "v", false, "Displays the extensions associated with each category")
    rootCmd.AddCommand(categoryListCmd)
}

// Execute the CLI tool
func Execute() {
    if err := rootCmd.Execute(); err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
}

// categoryListCmd prints all categories
var categoryListCmd = &cobra.Command{
    Use:   "category",
    Short: "Lists all file categories",
    Long:  "Displays a list of all categories used for organizing files, optionally with extensions.",
    Example: `org category 
org category --verbose`,
    Run: func(cmd *cobra.Command, args []string) {
        DisplayCategories(verbose)
    },
}

Step 5: Bringing It All Together with `main.go`

Here’s how everything ties together in main.go:

// main.go

package main

import (
    "your-project-path/cmd"
)

func main() {
    cmd.Execute()
}

Step 6: Running Your Tool and Testing Commands

Let’s give our tool a test drive! 🏎️ Open your terminal and run:

go run main.go display

If everything is set up correctly, you’ll see your categories displayed in a neat table. Now, you can easily add, remove, and display categories with just a few terminal commands. 🎉

Step 7: Building an Executable

Ready to share your creation with others? Let’s make it shareable by building an executable:

go build -o build/main

This command builds an executable that works on your device type. But what if you want your tool to run on multiple platforms? 🌐 Check out this DigitalOcean guide for instructions on cross-platform builds.

Bonus: Explore the Full Command Set

I’ve walked you through the first command, but there’s so much more you can do! 🧑‍💻 For the full set of commands, check out the GitHub repository here.

Conclusion

With Cobra powering our CLI, our File Organizer tool is now fully interactive and ready to take on the world! 🌍 Whether you’re organizing files for personal use or sharing the tool with friends, it’s now easier than ever to manage file categories.

So, what are you waiting for? Try it out, explore the commands, and build something awesome!

Let me know what you think in the comments or hit me up with feedback. Stay tuned for more cool projects with Golang! 🚀

My First Project using Golang (Part 2)

Boluwatife Adewusi — Wed, 02 Oct 2024 12:23:50 +0000

Part 2: Making File Organizer More Flexible 🎯

In Part 1, we explored how to organize files into categories such as images, audio, and documents by manually defining them in a map. But here’s the catch—what if you want to add another category or your friend wants to organize a new type of file? Right now, they would have to change the code and rebuild the tool, which isn't practical for everyone. 🛠️

In this part, we’re going to make File Organizer more flexible, allowing users to add or modify categories without having to write Go code. Exciting, right? Let’s dive in! 🌊

The Problem 🤔

As it stands, the only way to add a new file type is by modifying the ALLOWED_TYPES map in the source code. That’s fine if you're the only one using the tool, but if you want to share this with others, it can get tricky. Expecting everyone to know Go to make a simple change isn’t a good idea.

The Solution 💡

Now, here comes the fun part! Instead of hardcoding everything, we’re going to give File Organizer a makeover by making it much more user-friendly and flexible. 🌟

First off, we’ll find a more permanent storage solution for keeping track of our accepted file types and their corresponding folder names. This way, users won’t need to dig through code just to make changes.

Next up, we’ll implement some neat methods that give the user full control. They’ll be able to manipulate the file types they want to support and even customize the folder names to their liking—no Go knowledge required! 🛠️💻

To achieve all of this, we’re diving into the world of structs, interfaces, and receiver functions. And here’s the best part: we’ll add some CLI interactivity so users can easily interact with our tool without breaking a sweat. 🎮

Alright, enough talk—let’s get into it! ⚡

Defining the Custom Data Type 🛠️

Now, we’re going to level up our code! 💡 Instead of using the map data structure we had in Part 1, let’s define a custom data type to handle our file categories. This gives us more flexibility and makes our code a lot cleaner.

models/models.go

type FileCategory struct {
    FileType   string   `json:"file_type"`
    Extensions []string `json:"extensions"`
    FolderName string   `json:"folder_name"`
}

We’re taking advantage of Go’s ability to define custom types by using a struct. 🏗️ You’ll also notice this little piece of magic: json:"file_type" next to each declaration. Don't worry about that just yet—it’ll come in handy later. 😉

Introducing the DataStore Interface 🔗

Next up, we’re adding an interface that will be the backbone of our tool's flexibility. Why, you ask? Well, this interface enables users to make changes to file categories—like adding extensions or renaming folders.

models/models.go

type DataStore interface {
    AddCategory(fileType, folderName string, extensions []string) error
    RemoveCategory(fileType string) error
    AddExtensionsToCategory(fileType string, extensions []string) error
    RemoveExtensionsFromCategory(fileType string, extensions []string) error
    SetCategoryFolder(fileType, folderName string) error
    GetCategories() ([]*FileCategory, error)
    GetType(fileName string) (FileCategory, error)
}

Now, why do we need this? The simple answer: flexibility! By using an interface, we can easily swap out how we store the file categories—whether it’s a file-based storage solution or a full-blown database. 🗄️🔄 This ensures that any data source we choose conforms to the same methods, so you can change the storage solution without breaking the code. Talk about efficiency! 🔧💡

Final Touches to the `models.go` file

This all seems good but before we move to the implementation of the DataStore interface, let's add a couple of functions to the models file

models/models.go

func (c FileCategory) IsOfType(fileName string) bool {
    for _, ext := range c.Extensions {
        if strings.HasSuffix(fileName, ext) {
            return true
        }
    }
    return false
}

func (c FileCategory) MoveToFolder(src string) error {
    dest := filepath.Join(filepath.Dir(src), c.FolderName)

    if _, err := os.Stat(dest); os.IsNotExist(err) {
        err := os.Mkdir(dest, 0755)
        if err != nil {
            return err
        }
    }

    fileName := filepath.Base(src)

    err := os.Rename(src, filepath.Join(dest, fileName))

    if err != nil {
        return err
    }

    return nil
}

The IsOfType function checks whether a file matches any of the extensions in its category, while MoveToFolder does exactly what the name implies—moves files to the appropriate folder.

You might’ve noticed the syntax between func and the function name—this is where receiver functions come into play. In Go, receiver functions allow you to associate methods with a specific type (like our FileCategory struct). This means we can define behaviors directly on our structs, making them more functional and keeping our code clean and organized.

Implementing our DataStore

First, let's move our ALLOWED_TYPE map to a constants package

// constants/constants.go

package constants

var ALLOWED_TYPES = map[string][]string{
    "images":   {".jpg", ".jpeg", ".png", ".gif", ".svg", ".bmp", ".webp", ".psd", ".ico", ".heic", ".raw", ".ai"},
    "audio":    {".mp3", ".wav", ".flac", ".aac", ".ogg", ".m4a", ".wma", ".alac", ".aiff", ".pcm"},
    "video":    {".mp4", ".avi", ".mkv", ".mov", ".wmv", ".flv", ".webm", ".m4v", ".mpeg", ".3gp", ".ogg"},
    "document": {".doc", ".docx", ".pdf", ".txt", ".rtf", ".odt", ".ppt", ".pptx", ".xls", ".xlsx", ".csv", ".html", ".xml", ".md", ".epub", ".pages"},
}

Next, We are going to use the FileStorage as our datastore. Here's the implementation

// models/store_file.go

package models

import (
    "bufio"
    "encoding/json"
    "errors"
    "fmt"
    "os"
    "path/filepath"

    "your_project/constants"
)

// Define the store file name
const storeFileName = "store.json"

// FileDataStore struct to store the path
type FileDataStore struct {
    storagePath string
}

// New function creates a new instance of DataStore (FileDataStore)
func New(storagePath string) DataStore {
    storage := FileDataStore{storagePath: storagePath}
    storage.Init()
    return &storage
}

// Init initializes the file categories if they don't exist
func (f FileDataStore) Init() {
    _, err := f.GetCategories()
    if err != nil {
        dataStore := make([]*FileCategory, len(constants.ALLOWED_TYPES))
        index := 0
        for key, value := range constants.ALLOWED_TYPES {
            dataStore[index] = &FileCategory{
                FileType:   key,
                Extensions: value,
                FolderName: key,
            }
            index++
        }
        err = saveToFile(dataStore, filepath.Join(f.storagePath, storeFileName))

        if err != nil {
            panic(err)
        }
    }
}

// GetCategories retrieves stored categories from the JSON file
func (f FileDataStore) GetCategories() ([]*FileCategory, error) {
    file, err := os.Open(filepath.Join(f.storagePath, storeFileName))

    if err != nil {
        return nil, err
    }

    defer file.Close()

    scanner := bufio.NewScanner(file)
    jsonString := ""

    for scanner.Scan() {
        jsonString += scanner.Text()
    }

    var categories []*FileCategory
    err = json.Unmarshal([]byte(jsonString), &categories)

    if err != nil {
        return nil, err
    }

    return categories, nil
}

// GetType determines the category of a given file based on its extension
func (f FileDataStore) GetType(fileName string) (FileCategory, error) {
    categories, err := f.GetCategories()

    if err != nil {
        return FileCategory{}, err
    }

    for _, category := range categories {
        if category.IsOfType(fileName) {
            return *category, nil
        }
    }
    return FileCategory{}, errors.New(fmt.Sprintf("Category for File: %s not found", fileName))
}

// AddCategory allows adding new file categories
func (f FileDataStore) AddCategory(fileType string, folderName string, extensions []string) error {
    categories, err := f.GetCategories()

    if err != nil {
        return err
    }

    var fileCategory *FileCategory

    for _, category := range categories {
        if category.FileType == fileType {
            fileCategory = category
            break
        }
    }

    if fileCategory == nil {
        fileCategory = &FileCategory{
            FileType:   fileType,
            Extensions: extensions,
            FolderName: fileType,
        }

        if folderName != "" {
            fileCategory.FolderName = folderName
        }

        categories = append(categories, fileCategory)
    } else {
        fileCategory.Extensions = append(fileCategory.Extensions, extensions...)
        if folderName != "" {
            fileCategory.FolderName = folderName
        }
    }

    err = saveToFile(categories, filepath.Join(f.storagePath, storeFileName))

    if err != nil {
        return err
    }

    return nil
}

// RemoveCategory removes a file category by file type
func (f FileDataStore) RemoveCategory(fileType string) error {
    categories, err := f.GetCategories()

    if err != nil {
        return err
    }

    var updatedCategories []*FileCategory

    for _, category := range categories {
        if category.FileType != fileType {
            updatedCategories = append(updatedCategories, category)
        }
    }

    err = saveToFile(updatedCategories, filepath.Join(f.storagePath, storeFileName))

    if err != nil {
        return err
    }

    return nil
}

// AddExtensionsToCategory adds new extensions to a given file category
func (f FileDataStore) AddExtensionsToCategory(fileType string, extensions []string) error {
    categories, err := f.GetCategories()

    if err != nil {
        return err
    }

    for _, category := range categories {
        if category.FileType == fileType {
            category.Extensions = append(category.Extensions, extensions...)
            break
        }
    }

    err = saveToFile(categories, filepath.Join(f.storagePath, storeFileName))

    if err != nil {
        return err
    }

    return nil
}

// RemoveExtensionsFromCategory removes extensions from a given file category
func (f FileDataStore) RemoveExtensionsFromCategory(fileType string, extensions []string) error {
    categories, err := f.GetCategories()

    if err != nil {
        return err
    }

    for _, category := range categories {
        if category.FileType == fileType {
            for _, ext := range extensions {
                for i, existingExt := range category.Extensions {
                    if existingExt == ext {
                        category.Extensions = append(category.Extensions[:i], category.Extensions[i+1:]...)
                    }
                }
            }
        }
    }

    err = saveToFile(categories, filepath.Join(f.storagePath, storeFileName))

    if err != nil {
        return err
    }

    return nil
}

The New function returns a DataStore, but notice how we're actually returning a FileDataStore instance. How does that work without Go throwing an error? Well, this is thanks to Go's awesome feature: implicit interfaces! 🎉

In Go, as long as a type (like FileDataStore) implements all the methods defined in an interface (like DataStore), it automatically satisfies that interface. No need to explicitly declare it. So, since FileDataStore implements all the required methods, it’s treated as a DataStore by Go.

It's like Go saying, "You do the work? Great, you get the title!" 😎

Let's take it for a spin

go
main.go

package main

import (
    "your_project/models"
    "fmt"
    "os"
    "path/filepath"
)

func main() {
    //cmd.Execute()

    dataStore := models.NewFileDataStore("")

    displayCategories(dataStore)

    err := dataStore.AddCategory("private", "none_of_your_business", []string{".xyz", ".abc"})

    if err != nil {
        fmt.Printf("Add Category: %v", err)
        return
    }

    displayCategories(dataStore)

    organizeFiles("", dataStore)
}

func displayCategories(store models.DataStore) {
    categories, err := store.GetCategories()

    if err != nil {
        fmt.Printf("Get Categories: %v", err)
        return
    }

    fmt.Println("Category\t\t\t\t Folder Name\t\t\t\t")
    for _, category := range categories {
        fmt.Println(fmt.Sprintf("%s\t\t\t\t %s\t\t\t\t", category.FileType, category.FolderName))
    }

}

func organizeFiles(dir string, store models.DataStore) {
    files, err := os.ReadDir(dir)

    if err != nil {
        fmt.Println(err)
    }

    for _, file := range files {
        if file.IsDir() {
            continue
        }

        fileName := file.Name()

        category, err := store.GetType(fileName)

        if err != nil {
            fmt.Println(err)
            continue
        }

        err = category.MoveToFolder(filepath.Join(dir, fileName))

        if err != nil {
            fmt.Println(err)
            continue
        }

        fmt.Printf("%s moved to %s\n", fileName, filepath.Join(dir, category.FolderName, fileName))
    }
}

So far, everything’s shaping up nicely! But guess what? We’re just getting started. 🎉 Our application works, but it’s still missing that spark of interactivity. Imagine giving users the ability to tweak and manage categories right from the command line! 👨‍💻👩‍💻

In Part 3, we’re diving deeper and adding that layer of interaction to really bring this tool to life. Stay tuned—it's about to get way more fun and dynamic! ⚡

My First Project using Golang

Boluwatife Adewusi — Mon, 09 Sep 2024 10:53:08 +0000

🎉 Part 1: File Operations with Go

📝 Introduction

As a frontend developer with years of experience in JavaScript, I decided it was time for a new challenge. This year, I chose to dive into the world of Golang. To test my skills and add a practical tool to my arsenal, I created File Organizer—a command-line tool designed to bring order to the chaos of file management. 🚀

Imagine you’ve just finished a big project, and your directory is now a chaotic mess of images, audio files, videos, and documents. It’s a bit like having a beautifully decorated house but with all the furniture thrown haphazardly. 😩 I’ve been there, and it’s no fun at all!

In this first part of our adventure, we’ll focus on the basics of file operations in Go, learning how to sort and organize files into neat folders based on their extensions. Ready to dive in? Let’s go!

🕵️‍♂️ The Challenge

Ever felt overwhelmed by a cluttered directory? You’ve got a jumble of image files, audio clips, videos, and documents all mixed together. Sorting through them manually can feel like searching for a needle in a haystack. 😩

💡 Our Heroic Solution

We’re going to build a tool that transforms this mess into an organized paradise! Our File Organizer will automatically sort files into folders based on their type—images here, audio there, videos over here, and documents neatly tucked away. 🌟

🛠️ How We Made It Happen

Here’s how we crafted this file-sorting marvel:

1. Fetching the Directory Path

Our journey begins by finding out where our files are hiding. We expect the user to give us this directory on the command line, but how does our code get access to it? The module os to the rescue! 🚀 By calling os.Args, we gain access to a list of arguments the user provides when executing our code.

Here’s how we do it:

dir := os.Args[1]

We just pick the first argument in the slice

2. Reading the Directory

Next, we need to peek inside that directory to see what’s in there:

files, err := os.ReadDir(dir)
var filesToOrder []string

if err != nil {
    log.Fatal(err)
}

Here is the same os package again.
We read the contents of the directory, and if something goes wrong—like the directory doesn’t exist—our program will stop and tell us. 🚨

3. Skipping the Directories

Now, we need to focus on the files and leave directories behind:

for _, file := range files {
    if file.IsDir() {
        continue
    }
    filesToOrder = append(filesToOrder, file.Name())
}

Here, we loop through each item. If it’s a directory, we skip it. If it’s a file, we add it to our list of files to be organized. 🗂️

4. Sorting the Files

With our list of files ready, it’s time to sort them into their new homes:

for _, fileName := range filesToOrder {
    fileType := determineType(fileName)

    switch fileType {
    case IMAGE_TYPE:
        _ = moveToFolder(filepath.Join(dir, fileName), filepath.Join(dir, "images"))
    case AUDIO_TYPE:
        _ = moveToFolder(filepath.Join(dir, fileName), filepath.Join(dir, "audio"))
    case VIDEO_TYPE:
        _ = moveToFolder(filepath.Join(dir, fileName), filepath.Join(dir, "videos"))
    case DOCUMENT_TYPE:
        _ = moveToFolder(filepath.Join(dir, fileName), filepath.Join(dir, "documents"))
    default:
        fmt.Printf("Unsupported file type: %s\n", fileName)
    }
}

We loop through each file, figure out what type it is, and send it to the right folder. If we come across a file type we don’t recognize, we let you know. 🎯 You might be asking what determineType & moveToFolder are or maybe your editor is asking them of you already but don't worry, we will define them in the next section.

5. Determining File Types

To figure out what kind of file we’re dealing with, we use this handy function:

func determineType(file string) int {
    for key, value := range ALLOWED_TYPES {
        for _, ext := range value {
            if strings.HasSuffix(file, ext) {
                return key
            }
        }
    }
    return UNDEFINED_TYPE
}

It checks the file’s extension against our list and tells us whether it’s an image, audio, video, or document. 🕵️‍♂️ We use the strings package

6. Moving Files to Their New Homes

Finally, we move each file to its new folder:

func moveToFolder(src, dest string) error {
    if _, err := os.Stat(dest); os.IsNotExist(err) {
        err := os.Mkdir(dest, 0777)
        if err != nil {
            return err
        }
    }

    fileName := filepath.Base(src)

    err := os.Rename(src, filepath.Join(dest, fileName))

    if err != nil {
        return err
    }

    return nil
}

We check if the destination folder exists and create it if needed. Then we move the file from its old spot to the new one. 📁

7. Handling Unsupported File Types

For files that don’t fit into any category, we let you know:

default:
    fmt.Printf("Unsupported file type: %s\n", fileName)

We print a message for unsupported file types so you know exactly what didn’t get organized. 🚫

And that’s a wrap on Part 1! 🎉 We’ve successfully tackled the basics of file operations in Go and sorted our files into neat categories. But here’s a thought—what if you want to add a new category, like “Archives” or “Projects”? Right now, you’d have to dive into the map and tweak the code. 🤔

This approach is great if you’re the only one using the tool. But imagine sharing this awesome tool with friends who might not know Go. 🛠️ You’d want to make it easy for everyone to customize without needing to understand the code.

Fear not! In the next part, we’ll dive even deeper into the File Organizer tool and uncover advanced features that address these challenges. 🚀 We’ll make it so that anyone can tweak and enhance the tool without writing a single line of Go code. Intrigued? Stay tuned!

Got any questions or need more details? Drop them below, and let’s chat! 👇