feat: Cache default heatmap responses for 30 days

[marcodejongh]

Add caching to the heatmap API endpoint using Next.js unstable_cache, following the same pattern as the climb list caching. Default heatmap responses (no filters, no user authentication) are cached for 30 days using a cache key that includes board configuration parameters.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
boardsesh	Ready	Preview, Comment	Dec 31, 2025 0:57am

[claude]

Claude Review

Code duplication: sortObjectKeys function (lines 18-35) is duplicated from packages/web/app/lib/graphql/server-cached-client.ts (lines 44-61). Extract to a shared utility.

No other significant issues found.

[claude]

Claude Review

Potential Issue: User-specific data being cached globally

The cache key includes userId but the query at holds-heatmap.ts:106-157 fetches additional user-specific data (userAscents, userAttempts) when userId is provided and personal progress filters are NOT active. This means:

1. Cache poisoning risk: If user A requests heatmap first, their personal ascent/attempt data gets cached. User B (or anonymous users) could receive user A's personal data if the cache key logic has any edge cases.

2. 30-day cache for user data is too long: User ascent/attempt data changes frequently as users climb. Caching for 30 days means users won't see their progress reflected in the heatmap until cache expires.

Recommendation: Consider either:

• Only cache the non-user-specific branch (when userId is undefined)
• Use a shorter cache duration when userId is present (similar to how server-cached-client.ts uses 1 hour for filtered searches vs 30 days for default)
• Or skip caching entirely when user-specific data is requested

Minor: The sortObjectKeys function is duplicated between this file and server-cached-client.ts:44-61. Consider extracting to a shared utility.

[claude]

Claude Review

Missing search params in cache key (packages/web/app/api/v1/.../heatmap/route.ts:56-65): The cache key omits several SearchRequestPagination fields that could affect heatmap results:

• minRating
• onlyClassics
• onlyTallClimbs
• holdsFilter / hold_${number} keys
• page / pageSize (if pagination affects aggregation)

If any of these filters are used for heatmap queries, different filter combinations could incorrectly return cached results from different queries.

Minor: The sortObjectKeys function is duplicated between this file and server-cached-client.ts. Consider extracting to a shared utility to maintain consistency.

[claude]

Claude Review

No significant issues found.

Minor consideration:

• route.ts:51-58: The cachedFn is recreated on every call to cachedGetHoldHeatmapData. While unstable_cache internally deduplicates based on the cache key, creating the cached function at module level (or memoizing it) would be slightly more efficient. This is a minor optimization and not a bug.