End-to-end PRG → Go RTL → pgxpool → labdb queries → JSON response,
from a single 24 MB binary with no Node.js, FFI, or Apache anywhere
in the request path.
app/bridge_server.prg:
Main now opens a pgxpool handle from LABDB_DSN (or the local
Homebrew default) before HTTP_SERVER_START, then publishes it
via LABDB_SET_PG so request goroutines can pick it up.
BridgeDispatch calls FetchRouteData before the per-path PRG
handler runs. FetchRouteData maps a few /api/* routes to the
same SQL the upstream server.js endpoint runs, encodes results
via hb_jsonEncode, and stuffs them into ctx fields under the
same keys the existing labdb api/*.prg handlers already read
(rows, total, devices, etc.). PRG handlers stay unmodified.
hbrtl_ext/labdb_state/:
Tiny Go RTL that holds the PG handle in a sync/atomic.Int64.
Picked this over a PRG STATIC/PUBLIC variable to sidestep
Five's stricter parser (now that parser.go errors on missing
terminators, anything more elaborate in the entry .prg adds
friction without buying anything).
Verified against a Homebrew postgres@16 cluster seeded with 2 devices
+ 2 sessions:
/api/admin-stats.prg
→ {"devices":2,"sessions":2,"records":0,"active_sessions":1}
/api/sessions-list.prg
→ {"sessions":[...two rows with full fields...],"total":2}
/api/admin-devices.prg
→ {"devices":[...two rows with api_key/created_at...]}
/api/hello.prg (no DB)
→ unchanged from 1a.4-3
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Charles KWON OhJun
3bbfbb7010