ddidderr
8e1a1c91e2
New SQLite high-score databases were previously created empty, so the first shared table had no original entries. Seed only database paths that did not exist before opening with the ten distributed demo scores, while leaving existing files and in-memory stores unchanged. Add coverage for both first creation and existing empty files, and document the behavior. Test Plan: - `just test-highscore-server` -- passed (8 tests) - `just clippy-highscore-server` -- passed - `cargo +nightly fmt --manifest-path highscore-server/Cargo.toml -- --check` -- passed - `git diff --cached --check` -- passed
1.3 KiB
TDK high-score service
This small Axum service stores the shared top-ten table in SQLite. It exposes:
GET /healthz
GET /api/highscores
POST /api/highscores
The POST body is JSON with a 21-character maximum name and a u32 score. The
response is the canonical top-ten JSON array.
A newly created database starts with the original distributed demo table. An existing database, including an existing empty database, is left unchanged.
Submissions are anonymous and intentionally trust the browser's score. Add rate limiting, moderation, or server-side run verification if the table needs to resist forged scores.
Run it from tdkpin-rs with:
TDKPIN_HIGHSCORE_BIND=127.0.0.1:3000 \
TDKPIN_HIGHSCORE_DB=/var/lib/tdkpin/highscores.sqlite3 \
cargo run --manifest-path highscore-server/Cargo.toml
Copy the rate and connection zone declarations from
nginx.conf.example into the existing http block, then
place its two location blocks inside the public site's server block. The
example bounds per-client and aggregate API traffic, request bodies, and proxy
waits. The browser client expects the API at /api/highscores on the same
origin as the game.
The crate inherits the parent rustfmt.toml; run
just fmt-highscore-server when formatting it directly.