# Static Public Data

The web server serves `/data/*` from the same public data cache used by
`/api/tss/*`, and fills missing snapshots from the matching API route with a
short timeout. The frontend uses `/api/tss/*` by default; set
`VITE_STATIC_DATA=true` only for static-first experiments.

- `/data/leaderboard-teams.json`
- `/data/leaderboard-players.json`
- `/data/home-teams.json`
- `/data/recent-games.json`
- `/data/teams/{key}.json`
- `/data/teams/{key}.games.json`
- `/data/players/{key}.json`
- `/data/games/{key}.json`
- `/data/games/{key}.logs.json`

`{key}` is `encodeURIComponent(value).replace(/%/g, '~')`.

Snapshot files should keep the same response shape as the matching `/api/tss/*`
endpoint. Missing files are fine: the app remembers the miss for the current
browser session and uses the existing API route instead.

Do not generate every possible entity forever. Keep `/data` bounded:

- Always generate the small global snapshots: leaderboards, home teams, recent
  games.
- Generate team/player/game detail snapshots only for hot items, such as current
  leaderboard entries, recent games, recently viewed pages, or pinned items.
- Prune detail snapshots by age and access. For example: keep recent games for
  7-30 days, keep leaderboard teams/players while they remain ranked, and delete
  cold files that have not been refreshed recently.
- Write snapshots atomically (`file.tmp` then rename) so readers never see a
  partial JSON file.
- Serve compressed responses from the web server/CDN when possible. Keep source
  JSON minified unless humans need to inspect a fixture.