Static Public Data

The frontend can try these JSON snapshots before falling back to the live API when VITE_STATIC_DATA=true. By default, the app requests /api/tss/* directly and lets the web server answer from the same public data cache.

/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.