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
32 lines
1.2 KiB
Markdown
32 lines
1.2 KiB
Markdown
---
|
|
type: entity
|
|
tags: [parking, stack]
|
|
sources: [parking-system-architecture]
|
|
updated: 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.
|