Heimdall is listening.

Every request crosses a Bifrost — the rainbow bridge, and the object that carries a request in and a response back out. It threads through a chain of Runes (middleware), lands on a Handler, and may draw from Mímir's well to remember or recall rows. The whole framework is one Odin package split across a handful of files, each keeping its registration verb beside its logic.

Handlers are plain procedures of type proc(b: ^Bifrost) — Odin has no methods or closures, so the app is always passed by pointer. Register routes with the method verbs; literal paths should be declared before :param patterns so a capture never swallows a fixed segment.

// Literal routes before the :id pattern, else ":id" captures "schema".
gh.get(app, "/sample/schema", schema_handler)
gh.get(app, "/sample/:id", get_handler)

// CRUD against Postgres via Mímir. Method is matched before path.
gh.post(app, "/sample/:name", create_handler)      // create
gh.put(app, "/sample/:id/:name", update_handler)   // update
gh.delete(app, "/sample/:id", delete_handler)      // delete

get_handler :: proc(b: ^gh.Bifrost) {
    id, ok := gh.param_int(b, "id")
    if !ok {
        gh.text(b, 400, "id must be an integer")
        return
    }
    gh.json(b, 200, Sample{id = id, name = "thing"})
}

Mímir guards the well beneath Yggdrasil whose water is memory. Here your structs describe a shape and Mímir remembers it as rows. db: struct tags drive everything; you never write a CREATE TABLE. The well speaks a dialect (Postgres, MySQL, or SQLite) and — crucially — values never reach the SQL string. Every value is a bound parameter. That is the injection checkpoint, held end to end through the hand-rolled Postgres wire client.

// The "M" in MVC. Tags: column name, then flags.
Sample :: struct {
    id:   int    `db:"id,pk,auto"`,   // auto primary key
    name: string `db:"name,notnull"`, // required text
}

// Hand Mímir the model once; migrate() carves its table at run().
gh.remember(app, Sample)

Building procs need only the dialect; exec / query reach through the app's live connection. A handler draws its well straight from the Bifrost:

create_handler :: proc(b: ^gh.Bifrost) {
    name, _ := gh.param(b, "name")
    w := gh.well(b)
    rows, ok := gh.query(w, gh.offer(w, Sample{name = name}))
    if !ok {
        gh.text(b, 503, "database unavailable")
        return
    }
    id, _ := strconv.parse_int(rows.rows[0][0])  // the RETURNING id
    gh.json(b, 201, Sample{id = id, name = name})
}

At the well of Urðr the Norns weave the threads of fate; so here a template is the warp already strung on the loom, and weave runs the weft of your data through it to produce the finished cloth — HTML. The dialect is Jinja's, pared to its load-bearing parts: output an expression, pipe it through filters, branch with if, and iterate with for.

<!-- A template: the warp strung on the loom -->
<h1>{{ title | upper }}</h1>
{% if user %}<p>Welcome, {{ user.name }}.</p>{% else %}<p>Hail, stranger.</p>{% endif %}
<ul>
{% for n in norns %}  <li>{{ loop.index }}. {{ n | capitalize }}</li>
{% else %}  <li>the threads are cut</li>
{% endfor %}</ul>

Inside a for, a loop binding carries index / index0 / first / last / length, as in Jinja. You thread the context with warp (named values) and list (iterables), then weave:

ctx := gh.warp(
    {"title", "Gjallarhorn"},
    {"user", gh.warp({"name", "Heimdallr"})},
    {"norns", gh.list("urd", "verdandi", "skuld")},
)
html, _ := gh.weave(src, ctx)     // string in, woven HTML out

From a handler, render loads a template file, weaves a context through it, and sends it as HTML. Or mount a whole directory with the four-arg hail: a Provider builds the context fresh per request, so it can read the path, params, or the well.

// One file, one context, sent as text/html.
gh.render(b, "./templates/hello.html", ctx)

// Mount ./templates at /pages; GET /pages/x.html weaves templates/x.html.
gh.hail(&app, "/pages", "./templates", provider)