Charles KWON OhJun c72c2ff58d feat(bridge): port bridge_*.prg + wire HTTP↔bridge dispatcher
Pulls bridge_context.prg, bridge_request.prg, bridge_session.prg, and
bridge_cookie.prg from upstream fivenode into app/bridge/ so the
mod_harbour AP_* surface (AP_METHOD, AP_BODY, AP_ARGS, AP_USERIP,
AP_RPUTS, AP_JSONRESPONSE, AP_SETCONTENTTYPE, ctx_get, ctx_set, ...)
runs unchanged on top of fivenode_go's Go RTL.

bridge_main.prg deliberately omitted — its REQUEST sweep pulls in
TDrMySQL / hbct / hbcurl symbols fivenode_go neither has nor needs.
fivenode_go runs ahead-of-time with the Five compiler, so the
REQUEST trick that keeps fnb-runtime symbols alive isn't required.

One upstream patch was unavoidable: AP_RPUTS / AP_ECHO were variadic
(`( ... )`) and used PValue() to walk caller args. Five's PValue
returns the caller's LOCAL slot (not the actual variadic args, which
aren't copied into locals when declared params is 0), so the body
came back as "1" instead of the JSON payload. Collapsed both to a
single-argument form; every call site in fivenode_go already passes
exactly one value. Patched-out spots are marked with a TODO so we
can revert once Five gains real variadic PValue support.

app/bridge_server.prg ties it all together: starts httpserver on
:8090 with BRIDGEDISPATCH as the handler, hand-translates the Go
request hash into the ctx fields the AP_* layer reads, dispatches by
URL path (hard-coded /api/hello and /api/echo for now — file-name
dispatch lands in 1a.4), and assembles the response from the buffered
AP_* output + ctx_get("status") + ctx_get("headers_out").

Verified end-to-end:
  GET  /api/hello                       -> 200 JSON, method/ip echoed
  POST /api/echo?lang=ko (16-byte body) -> 200 JSON, body_parsed,
                                           query, user-agent
  GET  /api/nope                        -> 404 JSON

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-27 10:54:12 +09:00

fivenode_go

FiveNode for Five — a Harbour-compatible web framework that compiles to a single Go binary. No Node.js, no FFI, no Apache. PRG sources go in, one executable comes out.

Successor to the koffi/N-API based fivenode framework, rebuilt on the Five Pure-Go runtime.

Status

Early bootstrap — Phase 1a in progress.

Architecture

Browser ──── HTTP/HTTPS ──── fivenode_go single binary
                              ├─ Five hbrt VM (PRG interpreter / compiled)
                              ├─ Five hbrtl (483 standard RTL functions)
                              ├─ hbrtl_ext/httpserver  — HTTP server RTL
                              ├─ hbrtl_ext/capi        — bridge_*.prg helpers
                              ├─ hbrtl_ext/pgrtl       — PostgreSQL client RTL
                              ├─ app/                  — bridge_*.prg + app PRG
                              └─ go:embed              — static assets

fnode build api/*.prg --extra-rtl=hbrtl_ext/... -o myapp produces a self-contained binary. No external dependencies beyond what the app code itself opens (e.g. a Postgres connection).

Build

go build -o fnode ./cmd/fnode
./fnode build app/hello.prg -o hello
./hello

License

Copyright (c) 2026 Charles KWON OhJun. All rights reserved.

Description
FiveNode for Five — Harbour PRG web framework as a single Go binary (no Node.js, no FFI)
Readme 139 KiB
Languages
xBase 44.2%
Go 35.8%
HTML 10.2%
CSS 8.1%
JavaScript 1.7%