julian
96acd6b662
Camera snapshots were stored RAW — the camera's full-res JPEG straight into the BLOB, no resize/recompress. Measured on the dev DB: 300 snapshots = 81.7 MB = ~72% of the 114 MB SQLite file (the big ones 2688×1520 / ~600 KB, Hikvision main stream). They dominated the appliance's single backed-up DB file. Re-encode on capture (snapshot.ts): - Downscale each frame to SNAPSHOT_MAX_EDGE (1280px long edge) + recompress at SNAPSHOT_JPEG_QUALITY (80) via sharp (libvips, Apache-2.0) before storage — ~6-10× smaller (verified 2688×1520 → 1280×724, ~8×), plate still readable, clean image/jpeg (drops the camera's charset cruft). STORAGE-ONLY: recognition keeps the ORIGINAL full-res bytes (downscaling hurts OCR). Fail-soft — a re-encode error stores the original, never drops the snapshot or blocks the (already-open) path. sharp lives in apps/server (owns the capture path), where bcrypt already establishes the native-dep pattern. Disk-pressure retention (snapshot-retention.ts) — a SAFETY VALVE, not the daily mechanism (the re-encode does that). Daily check reads the DB filesystem used% (statfs on db.$client.name); no-op unless ≥ SNAPSHOT_DISK_HIGH_PCT (70). Over the mark: delete the OLDEST until an estimated SNAPSHOT_DISK_FREE_TARGET_PCT (10%) of disk is freed — never below SNAPSHOT_MIN_KEEP (500) — then VACUUM once to return space to the OS. A DELETE only frees SQLite pages (disk doesn't drop until VACUUM), so the loop is driven by estimated freed bytes (SUM(length(bytes))), not a live disk re-read; the prune owns the DB-locking VACUUM, run daily off-peak. diskUsage is injectable for tests. None of this touches the signed ledger — snapshots are unsigned/advisory, referenced only by id. Tests: encodeForStorage (downscale / clean-type / no-enlarge / fail-soft) + pruneSnapshots (no-op below mark / delete-oldest-to-target + VACUUM / MIN_KEEP floor / skip-VACUUM-when-empty). All four snapshot env knobs documented in the komodo env reference. Full workspace build/lint/test green; the prune smoke-verified on a scratch DB copy (file shrank after VACUUM). Existing ~81.7 MB of raw snapshots are unchanged (a one-off re-encode backfill is a separate optional follow-up). Updated entry-exit-points + technology-stack wiki. Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
1.2 KiB
1.2 KiB
type, tags, sources, updated
| type | tags | sources | updated | |||
|---|---|---|---|---|---|---|
| entity |
|
|
2026-06-14 |
Technology Stack
The standing stack for the parking system. Every choice is MIT/Apache/BSD — a deliberate constraint to avoid vendor lock-in and license rug-pulls (see payload-cms for the cautionary case). (See parking-system-architecture §2.)
| Layer | Choice | License |
|---|---|---|
| Monorepo | turborepo | MIT |
| Backend | fastify (Node.js) | MIT |
| Frontend | react-vite-spa | MIT |
| Local database | sqlite (better-sqlite3) |
Public domain / BSD |
| ORM | drizzle-orm (+ Drizzle Kit) | Apache 2.0 |
| Remote sync target | PostgreSQL (when implemented) | PostgreSQL License |
| Auth | local-jwt-auth (@fastify/jwt + bcrypt + roles) |
MIT |
| Image processing | sharp (libvips) — snapshot re-encode/downscale on the server |
Apache 2.0 |
Why these
One language end-to-end (Node), a mature ecosystem for device I/O (serialport, node-hid,
escpos), and a database whose only real limit (single-writer) a parking workload never
approaches. The stack is shaped by offline-first: nothing depends on a network at runtime.
See standing-decisions for the full list of settled decisions.