DEV Community: Nicole Akinyi

Building a Server-Rendered Forum in Go: Auth, SQLite, and Docker Without a Framework

Nicole Akinyi — Thu, 06 Aug 2026 08:22:48 +0000

Most forum tutorials reach for a framework and a hosted database on day one. Working on a four-person team building a forum from scratch in Go with no framework, SQLite as the only datastore, and server-side rendering instead of a JavaScript frontend, taught me more about what a web framework is actually doing for you than any amount of reading framework documentation ever did. This article walks through the real architectural decisions and problems that come up when you build this stack directly on top of Go's standard library.

Why no framework, and why SQLite

The constraint was deliberate: standard library net/http for routing and handlers, html/template for rendering, and SQLite as the only database, all wrapped in Docker for a reproducible environment across four different development machines. No Gin, no Echo, no ORM.

This sounds like unnecessary hardship until you actually do it, at which point it becomes clear how much conceptual clarity you get in exchange. Every request handler, every SQL query, every session check is something you wrote and can trace, which matters enormously when four people are debugging the same codebase and nobody wants to also be debugging an unfamiliar framework's internals at the same time.

SQLite specifically is a better fit for this kind of project than people expect. It is a single file, it needs no separate server process, it supports concurrent reads without configuration, and it is genuinely fast enough for a forum's read-heavy workload. The one thing you have to be deliberate about is write concurrency, which I will come back to.

Project structure and team ownership

With four people working in one repository, structure is not a nicety, it is what prevents constant merge conflicts. We split ownership along clear boundaries: one person owned the Docker setup and README, others owned authentication, post/thread handling, and the templating layer respectively. That division only works if the package structure actually enforces it.

cmd/
  server/
    main.go
internal/
  auth/
    session.go
    handlers.go
internal/
  forum/
    thread.go
    post.go
    handlers.go
internal/
  db/
    schema.sql
    queries.go
web/
  templates/
  static/
Dockerfile
docker-compose.yml
README.md

Keeping db as its own package with a single queries.go file that every other package imports through, rather than letting auth and forum each open their own connections and write their own SQL, turned out to be the single decision that saved the most integration pain. It meant schema changes had one place to happen, and it meant the SQLite write-concurrency issue described below only needed to be solved once.

Schema-first with plain SQL

No ORM means the schema is the actual source of truth, hand-written and versioned:

CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    username TEXT UNIQUE NOT NULL,
    email TEXT UNIQUE NOT NULL,
    password_hash TEXT NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE threads (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id INTEGER NOT NULL REFERENCES users(id),
    title TEXT NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE posts (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    thread_id INTEGER NOT NULL REFERENCES threads(id),
    user_id INTEGER NOT NULL REFERENCES users(id),
    body TEXT NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE sessions (
    id TEXT PRIMARY KEY,
    user_id INTEGER NOT NULL REFERENCES users(id),
    expires_at DATETIME NOT NULL
);

Queries are written as plain SQL strings paired with typed Go functions, using database/sql with the mattn/go-sqlite3 driver:

func GetThreadWithPosts(db *sql.DB, threadID int64) (*Thread, []Post, error) {
    var t Thread
    err := db.QueryRow(
        `SELECT id, user_id, title, created_at FROM threads WHERE id = ?`,
        threadID,
    ).Scan(&t.ID, &t.UserID, &t.Title, &t.CreatedAt)
    if err != nil {
        return nil, nil, err
    }

    rows, err := db.Query(
        `SELECT id, user_id, body, created_at FROM posts WHERE thread_id = ? ORDER BY created_at ASC`,
        threadID,
    )
    if err != nil {
        return nil, nil, err
    }
    defer rows.Close()

    var posts []Post
    for rows.Next() {
        var p Post
        if err := rows.Scan(&p.ID, &p.UserID, &p.Body, &p.CreatedAt); err != nil {
            return nil, nil, err
        }
        posts = append(posts, p)
    }
    return &t, posts, rows.Err()
}

Writing SQL by hand instead of through an ORM makes N+1 query problems visible immediately, because you feel every extra round trip you write. The thread-and-posts fetch above is intentionally two queries rather than a join, because SQLite handles this pattern well and it keeps the Go-side struct mapping simple, but it is a decision made consciously rather than one an ORM made invisibly on your behalf.

The SQLite write-concurrency problem

SQLite handles concurrent reads without issue, but by default only one write can happen at a time across the entire database file, and a second writer arriving while one is in progress gets a database is locked error rather than waiting. On a forum, where posting is the single most common write action and four people are hammering the same dev database while testing, this surfaces almost immediately.

The fix has two parts. First, enable write-ahead logging, which lets reads proceed concurrently with a single writer instead of blocking on it:

db.Exec("PRAGMA journal_mode=WAL;")

Second, set a busy timeout so that a write which arrives while another write is in progress waits and retries instead of failing immediately:

db.Exec("PRAGMA busy_timeout=5000;")

Both of these are one-line fixes, but only if you know to look for them. Without them, the first real concurrent-write test looks like a serious database bug rather than a two-line configuration gap, and it is exactly the kind of thing that eats an afternoon of debugging effort chasing the wrong cause.

Authentication with plain sessions

No JWT library, no third-party auth service. Sessions are random tokens stored in the sessions table and set as an HTTP-only cookie:

func CreateSession(db *sql.DB, userID int64) (string, error) {
    token := generateSecureToken(32)
    expires := time.Now().Add(24 * time.Hour)
    _, err := db.Exec(
        `INSERT INTO sessions (id, user_id, expires_at) VALUES (?, ?, ?)`,
        token, userID, expires,
    )
    return token, err
}

func SetSessionCookie(w http.ResponseWriter, token string) {
    http.SetCookie(w, &http.Cookie{
        Name:     "session",
        Value:    token,
        HttpOnly: true,
        Secure:   true,
        SameSite: http.SameSiteStrictMode,
        Path:     "/",
        Expires:  time.Now().Add(24 * time.Hour),
    })
}

HttpOnly prevents JavaScript from reading the cookie, which matters for a forum where user-submitted content eventually ends up rendered on the page and you want session theft via a missed escaping bug to be as hard as possible even as a fallback layer. SameSiteStrictMode cuts down on cross-site request forgery exposure for a login-gated app like this.

Middleware checks the session on every protected route:

func RequireAuth(db *sql.DB, next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        cookie, err := r.Cookie("session")
        if err != nil {
            http.Redirect(w, r, "/login", http.StatusSeeOther)
            return
        }
        var userID int64
        var expiresAt time.Time
        err = db.QueryRow(
            `SELECT user_id, expires_at FROM sessions WHERE id = ?`,
            cookie.Value,
        ).Scan(&userID, &expiresAt)
        if err != nil || time.Now().After(expiresAt) {
            http.Redirect(w, r, "/login", http.StatusSeeOther)
            return
        }
        ctx := context.WithValue(r.Context(), userContextKey, userID)
        next(w, r.WithContext(ctx))
    }
}

Server-side rendering with html/template, and why escaping matters here specifically

html/template, not text/template, is the entire reason server-rendered user content is safe by default in Go. It automatically contextually escapes output based on where in the HTML it lands, so a post body containing <script> tags gets rendered as inert text rather than executed. This one package-name difference is doing a substantial amount of the security work that a framework would otherwise be doing for you, and it is easy to not appreciate how much until you deliberately try text/template on user content and watch it happily inject raw HTML.

var tmpl = template.Must(template.ParseFiles(
    "web/templates/layout.html",
    "web/templates/thread.html",
))

func ThreadHandler(w http.ResponseWriter, r *http.Request) {
    threadID, _ := strconv.ParseInt(r.PathValue("id"), 10, 64)
    thread, posts, err := forum.GetThreadWithPosts(db, threadID)
    if err != nil {
        http.Error(w, "thread not found", http.StatusNotFound)
        return
    }
    data := struct {
        Thread *forum.Thread
        Posts  []forum.Post
    }{thread, posts}
    tmpl.ExecuteTemplate(w, "layout.html", data)
}

Dockerizing a CGo-dependent binary

mattn/go-sqlite3 uses CGo, which is the detail that trips people up when they try to build a minimal container the way they would for a pure-Go binary. A standard scratch-based multi-stage build fails because CGo binaries need libc at runtime, which scratch does not provide.

FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=1 GOOS=linux go build -o forum ./cmd/server

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y ca-certificates && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY --from=builder /app/forum .
COPY --from=builder /app/web ./web
COPY --from=builder /app/internal/db/schema.sql ./internal/db/schema.sql
VOLUME /app/data
EXPOSE 8080
CMD ["./forum"]

debian:bookworm-slim as the runtime base instead of scratch or alpine is the fix: it has the glibc that the CGo-linked SQLite driver needs, at a much smaller footprint than the full golang build image. The VOLUME directive for the SQLite file matters too, since without it the database resets every time the container is recreated, which is exactly the kind of thing that looks like a data-loss bug during development but is actually just default container filesystem behavior doing what it always does.

What this stack teaches you that a framework hides

Building this without a framework surfaces decisions that are normally made invisibly on your behalf: how sessions are stored and validated, how a database driver's linking model interacts with your container's base image, how a templating engine's escaping behavior is the actual security boundary between user input and rendered HTML. None of these are exotic problems. They are the ordinary, load-bearing decisions that a framework typically makes for you by default, and building without one is less about reinventing wheels and more about finally seeing the wheels that were always there.

Why Your Commit History Can Fail an Audit Even When Your Code Works

Nicole Akinyi — Thu, 06 Aug 2026 08:20:23 +0000

There is a category of bug that never shows up in your test suite, never throws an exception, and can still get an entire project rejected: unclear ownership in your git history. I learned this the expensive way on a two-person Go web project where the application itself worked correctly and still failed its audit, purely because it was impossible to tell from the commit log who had actually written which parts of the code.

This is not a story about git commands. It is a story about what "collaboration" actually needs to look like in version control when someone else is going to evaluate your individual contribution, and what to do when you discover, partway through a project, that your history does not support that evaluation.

The setup

The project was a web application built with a partner, split roughly into a backend API and a frontend consisting of templates, display logic, and styling. We worked the way a lot of early collaborators work: sharing a single local checkout at points, committing under whichever git identity happened to be configured on the machine at the time, and occasionally pushing each other's uncommitted changes to save time. None of this was malicious. It was just imprecise, and imprecision in git history reads, from the outside, exactly like dishonesty.

What the audit actually checks

An audit of a collaborative project is not primarily checking whether the software works. It is checking whether the git history is a truthful record of who did what. That distinction matters enormously and most people do not internalize it until it costs them. A working application built by two people with a commit history that cannot distinguish their contributions is, from an evaluation standpoint, indistinguishable from a project where one person did all the work and the other person's name is attached for free.

The specific failure in my case was that a meaningful chunk of frontend commits were attributed to my partner's git identity, despite the actual authorship being mine, because we had been sharing a working directory without reconfiguring user.name and user.email between sessions. There was no way, looking at the log, to verify that I had done the frontend work at all. The audit did not accuse anyone of lying. It just correctly identified that the evidence needed to confirm individual contribution was not there, and treated that absence as a failure condition.

The fix: rebuild on a clean branch under your own identity

Once you are in this situation, trying to rewrite history on the shared branch is usually worse than starting fresh, especially if your partner has already pushed further work on top of the tangled commits. Rewriting shared history creates its own trust problems and can look like you are trying to obscure something rather than fix it.

What worked was creating a new branch specifically for my portion of the work, checking out the current state of the frontend files, and recommitting them incrementally under my own git identity, with commit messages that actually described the work in a way that a reader unfamiliar with the project could follow.

First, confirm which identity git will actually use for new commits, since this is the exact thing that went wrong the first time:

git config user.name
git config user.email

If either one is missing or wrong for the current session, set it explicitly, and for a shared machine, set it locally to the repository rather than globally so it cannot silently apply to someone else's work later:

git config user.name "Your Actual Name"
git config user.email "your-actual-email@example.com"

From there, I created a dedicated branch off the current shared state:

git checkout -b coley-frontend

Rather than trying to cherry-pick or rebase the tangled commits, which would have carried the wrong authorship metadata along with them, I treated the frontend directory as a fresh contribution. I removed the frontend files, then reintroduced them in a sequence of small, honestly-described commits:

git rm -r --cached templates/ static/
git commit -m "remove frontend files pending rebuild under correct authorship"

# then, restoring and recommitting incrementally:
git add templates/base.html templates/layout.html
git commit -m "add base and layout templates"

git add static/css/main.css
git commit -m "add primary stylesheet"

git add templates/thread.html templates/post.html
git commit -m "add thread and post display templates"

Each commit was small enough and specific enough that its content matched its message, which is a detail auditors specifically look for. A commit message that says "add thread and post display templates" attached to a diff that actually touches unrelated backend files is its own kind of red flag, arguably worse than vague messages, because it suggests the commits were constructed after the fact rather than reflecting the actual order of work.

Verifying authorship before you submit

Do not just trust that the rebuild worked. Check it the same way an auditor would:

git log --author="your-actual-email@example.com" --oneline

This should show a coherent, chronological set of commits that plausibly represents the frontend work you are claiming. If commits from your partner's identity are interleaved in a way that does not make sense, or if your commits are all clustered in a suspicious burst right before a deadline, that is worth noticing and addressing before someone else notices it for you.

It is also worth running git log --stat on your own commits to confirm the file changes attached to each one are what you expect:

git log --stat --author="your-actual-email@example.com"

What to do differently from day one on the next project

The rebuild was the right emergency fix, but the actual lesson is upstream of git commands entirely. A few habits prevent this situation from happening in the first place.

Set your git identity locally per repository, every time, before your first commit, rather than assuming a global config is correct:

git config --local user.name "Your Name"
git config --local user.email "you@example.com"

Never share a single working directory between collaborators for parallel work on different areas of the codebase. Each person should have their own clone, working on their own branch, pushing their own commits, even if you are pair programming in the same room. Shared directories are where identity mixing happens, almost always by accident rather than intent.

Commit in small, single-purpose chunks as you go rather than batching a day's work into one large commit at the end. Small commits are not just good practice for readability, they are also what makes it possible to verify, after the fact, that the pattern of work matches a real development process rather than a reconstruction.

Agree explicitly, before the project starts, on how ownership will be divided and documented, especially if the audit process weighs individual contribution. This conversation feels unnecessary when you trust your collaborator, and it is precisely the kind of thing that is expensive to skip and cheap to have upfront.

The broader point

Git history is not just a backup mechanism or a way to undo mistakes. On any project where individual accountability matters, whether that is a school audit, a job interview asking you to walk through your GitHub, or a workplace performance review, your commit log is a piece of evidence about your actual work, and it is evidence that other people will read literally. A codebase that works perfectly can still tell a false story about who built it, and once you have been on the wrong end of that once, you start treating every git commit as something closer to a signed statement than a convenience command.

How ASCII Art Banner Rendering Actually Works: Parsing, Alignment, and the Edge Cases That Break It

Nicole Akinyi — Thu, 06 Aug 2026 08:16:55 +0000

ASCII art generators look trivial from the outside: take some text, print it in a blocky font made of characters, done. Having built one as a terminal application and then again as a browser-accessible web server in Go, I can say the actual difficulty is almost entirely in the parsing and edge-case handling, not in the printing. This article covers the real mechanics of turning a banner font file into rendered text output, and the specific failure modes that a naive implementation runs into.

What a banner file actually is

A banner file is a plain text file that encodes an entire font, one character at a time, using ASCII characters arranged in a fixed-height block. A typical format reserves a fixed number of lines per character, commonly 8 lines representing the printable ASCII range from space through tilde, with each character's glyph occupying that many consecutive lines before the next character's glyph begins.

A tiny excerpt for the letter A might look like:

 _
/ \
|_|
| |

with each line being one row of the glyph, and the glyph itself spanning a fixed number of rows regardless of how many of those rows are actually "filled in" for that particular character. A period or a space typically renders as mostly or entirely blank rows, but it still occupies the full row count, because the whole scheme depends on every character's glyph having identical height so that lines can be assembled predictably.

The core rendering algorithm

The naive-sounding approach is actually correct here, which is a nice change from the max-flow situation in a different project: for each line of input text, you render that line by, for each row index from 0 to the glyph height, concatenating the corresponding row of every character's glyph in sequence, left to right, then moving to the next row index, until all rows for that line of text have been printed.

const glyphHeight = 8

func RenderLine(text string, font map[rune][]string) string {
    if text == "" {
        return strings.Repeat("\n", glyphHeight-1) + "\n"
    }

    var rows [glyphHeight]strings.Builder
    for _, ch := range text {
        glyph, ok := font[ch]
        if !ok {
            continue
        }
        for row := 0; row < glyphHeight; row++ {
            rows[row].WriteString(glyph[row])
        }
    }

    var out strings.Builder
    for row := 0; row < glyphHeight; row++ {
        out.WriteString(rows[row].String())
        out.WriteByte('\n')
    }
    return out.String()
}

This is the entire rendering logic, and it is genuinely almost that simple. Everything that makes an ASCII art tool hard to get right lives in the parsing step that builds the font map[rune][]string, and in a handful of edge cases around input handling that are easy to overlook until a test case exposes them.

Parsing the banner file correctly

The parsing challenge is that the banner file is just a flat sequence of lines with no explicit markers saying where one character's glyph ends and the next begins. You have to derive that boundary purely from position, using the fact that the printable ASCII range starts at space (decimal 32) and that each glyph occupies a known, fixed number of lines.

func ParseFont(data []byte) (map[rune][]string, error) {
    lines := strings.Split(string(data), "\n")

    font := make(map[rune][]string)
    current := rune(32) // space is the first printable character

    for i := 0; i+glyphHeight <= len(lines); i += glyphHeight {
        glyph := lines[i : i+glyphHeight]
        font[current] = glyph
        current++
        if current > '~' {
            break
        }
    }

    if len(font) == 0 {
        return nil, fmt.Errorf("font file contained no complete glyphs")
    }
    return font, nil
}

The off-by-one errors here are the most common source of bugs, and they are the kind of bug that is very easy to introduce and very hard to spot by eye, because a font that is shifted by even one line still renders something that looks like plausible ASCII art, just for the wrong characters. If your banner file has a leading blank line before the first glyph, or a trailing blank line after the last one, or uses a blank-line separator between glyphs that you are not accounting for in your height calculation, every single character in your rendered output silently shifts to represent the wrong glyph, and the bug can go unnoticed for a long time because the output still looks like art, just art for a different string than the one you asked for.

The defense against this is not cleverness, it is a specific, boring kind of test: render one known character, by itself, and diff it byte-for-byte against the exact expected glyph copied straight out of the font file. Doing this for the first and last characters in the printable range in particular catches most indexing bugs immediately, because those are the positions most likely to be affected by a miscounted offset.

Edge case one: newlines inside the input string

The most common real bug report on a project like this is "\n doesn't work," referring to a user passing a literal newline character inside their input text, expecting it to start a new banner line, and it just not being handled, because the renderer as written above treats the entire input as one line to be rendered as one block of glyph rows.

The fix is to split on newlines before rendering, and render each resulting segment as its own independent block:

func Render(text string, font map[rune][]string) string {
    segments := strings.Split(text, "\n")
    var out strings.Builder
    for _, seg := range segments {
        out.WriteString(RenderLine(seg, font))
    }
    return out.String()
}

The subtlety worth calling out is what happens with an empty segment, which occurs whenever the input has two consecutive newlines or a trailing newline. An empty segment needs to still produce a blank line in the output, specifically glyphHeight worth of newline characters representing an empty banner row, rather than producing nothing at all, or the visual spacing of multi-line input silently collapses and no longer matches what the user typed.

Edge case two: characters outside the supported range

Input text will eventually contain a character that is not in your font map, whether that is an unsupported symbol, an emoji, or a character from outside the ASCII range entirely. The naive approach in the render loop above, silently skipping unknown characters, is a defensible choice, but it is a choice, and it needs to be a deliberate one rather than an accident, because the alternative, a program that panics or produces garbled output on unexpected input, is a much worse experience for anyone actually using the tool.

func RenderLine(text string, font map[rune][]string) (string, []rune) {
    var unsupported []rune
    var rows [glyphHeight]strings.Builder

    for _, ch := range text {
        glyph, ok := font[ch]
        if !ok {
            unsupported = append(unsupported, ch)
            continue
        }
        for row := 0; row < glyphHeight; row++ {
            rows[row].WriteString(glyph[row])
        }
    }

    var out strings.Builder
    for row := 0; row < glyphHeight; row++ {
        out.WriteString(rows[row].String())
        out.WriteByte('\n')
    }
    return out.String(), unsupported
}

Returning the list of unsupported characters alongside the rendered output, rather than swallowing that information, lets the caller decide how to surface it, whether that is a warning message in a CLI tool or a validation error in a web form, instead of baking that decision into the rendering function itself.

Taking it from CLI to a web server

The move from a terminal tool to an HTTP server version of the same renderer sounds like it should just be wrapping the existing function in a handler, and functionally, it mostly is:

func RenderHandler(font map[rune][]string) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        text := r.FormValue("text")
        if text == "" {
            http.Error(w, "text parameter is required", http.StatusBadRequest)
            return
        }
        if len(text) > 1000 {
            http.Error(w, "input too long", http.StatusBadRequest)
            return
        }
        output, unsupported := RenderLineSet(text, font)
        if len(unsupported) > 0 {
            w.Header().Set("X-Unsupported-Characters", fmt.Sprintf("%d", len(unsupported)))
        }
        w.Header().Set("Content-Type", "text/plain; charset=utf-8")
        fmt.Fprint(w, output)
    }
}

What actually changes meaningfully between the CLI and web versions is input trust. A CLI tool run by the person who wrote it can reasonably assume well-formed input. An HTTP handler accepting form input from arbitrary requests cannot, which is why the length check and the required-field check exist in the handler above and did not need to exist in the original command-line version at all. The rendering algorithm itself does not change; the boundary of what you are willing to trust does.

The general lesson

The rendering step in a project like this is close to trivial once you have the font parsed correctly, which is a pattern that shows up constantly in software that manipulates structured text or binary formats: the transformation logic is usually the easy part, and the actual engineering effort goes into correctly parsing the input format and handling the edge cases at its boundaries. It is worth noticing when a piece of code you are about to write fits that pattern, because it changes where you should actually spend your debugging and testing effort. Test the parser exhaustively against known-good output first. The renderer built on top of a correctly parsed font will very often just work.