Improve click caches #2470
Improve click caches #2470
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThe changes primarily involve renaming the Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API
participant RecordClickCache
participant Redis
Client->>API: Track Click/Visit/Lead
API->>RecordClickCache: Generate cache key
RecordClickCache->>Redis: Get/Set click data
Redis-->>RecordClickCache: Return cached data
RecordClickCache-->>API: Return result
API-->>Client: Respond with tracking status
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/web/lib/middleware/link.ts (1)
253-253: Prefer nullish coalescing for clarity
Using||may coerce other falsy values (e.g., empty strings) intoundefined. To be more precise, consider:- clickId = (await recordClickCache.get({ domain, key, ip })) || undefined; + const cached = await recordClickCache.get({ domain, key, ip }); + clickId = cached ?? undefined;apps/web/app/(ee)/api/track/lead/route.ts (1)
97-107: Clarify and strengthen fallback logic for click data
The dual-key lookup is helpful, but we should make the comment and types more descriptive to aid future maintenance:- // revert after 5 mins - const cachedClickData = await redis - .mget< - ClickData[] - >([`clickIdCache:${clickId}`, `clickCache:${clickId}`]) - .then(([clickIdCache, clickCache]) => { - if (clickIdCache) { - return clickIdCache; - } - return clickCache; - }); + // Fallback for delayed ingestion: try new 'clickIdCache' then legacy 'clickCache' (5 min TTL) + const [newCache, legacyCache] = await redis.mget< + [ClickData | null, ClickData | null] + >([ + `clickIdCache:${clickId}`, + `clickCache:${clickId}` + ]); + const cachedClickData = newCache ?? legacyCache;This refactor:
- Renames variables for clarity (
newCache,legacyCache).- Uses tuple typing for
mget.- Updates the comment to explain why we fallback.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
apps/web/app/(ee)/api/track/click/route.ts(2 hunks)apps/web/app/(ee)/api/track/lead/route.ts(1 hunks)apps/web/app/(ee)/api/track/visit/route.ts(2 hunks)apps/web/lib/api/links/record-click-cache.ts(2 hunks)apps/web/lib/middleware/link.ts(2 hunks)apps/web/lib/tinybird/record-click.ts(3 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (4)
apps/web/lib/middleware/link.ts (1)
apps/web/lib/api/links/record-click-cache.ts (1)
recordClickCache(28-28)
apps/web/app/(ee)/api/track/click/route.ts (1)
apps/web/lib/api/links/record-click-cache.ts (1)
recordClickCache(28-28)
apps/web/lib/tinybird/record-click.ts (1)
apps/web/lib/api/links/record-click-cache.ts (1)
recordClickCache(28-28)
apps/web/app/(ee)/api/track/visit/route.ts (1)
apps/web/lib/api/links/record-click-cache.ts (1)
recordClickCache(28-28)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
🔇 Additional comments (11)
apps/web/lib/middleware/link.ts (1)
30-30: Align import to renamed cache instance
The import has been correctly updated fromclickCachetorecordClickCache, matching the new modulerecord-click-cache.tsand keeping consistency across the codebase.apps/web/app/(ee)/api/track/click/route.ts (2)
4-4: Update import to use the renamed cache
Switching from the oldclickCacheimport torecordClickCacheensures alignment with the renamedRecordClickCacheclass inrecord-click-cache.ts.
63-63: Fetch cached click ID using the new cache key
The call torecordClickCache._createKeycorrectly replaces the previousclickCachekey generation, preserving fallback tolinkCachefor link data.apps/web/app/(ee)/api/track/visit/route.ts (2)
4-4: Update import to use the renamed cache
ImportingrecordClickCachefromrecord-click-cache.tsreflects the refactored cache instance and removes the outdatedclickCache.
45-45: Fetch visit click ID with the new cache key
UsingrecordClickCache._createKeyhere correctly generates the new Redis key for click IDs while still falling back tolinkCachefor link metadata.apps/web/lib/api/links/record-click-cache.ts (2)
12-12: Rename cache class toRecordClickCache
The class has been renamed to reflect its purpose more accurately. This change dovetails with import updates across the codebase.
28-28: Export the correctly renamed cache instance
ExportingrecordClickCacheensures all consumers refer to the new instance backed byRecordClickCache.apps/web/lib/tinybird/record-click.ts (4)
11-11: ImportrecordClickCacheinstead ofclickCache
The updated import path and identifier correctly reflect the renamed cache class and singleton instance.
85-85: Replace rate-limit lookup withrecordClickCache.get
Using the new cache API to dedupe clicks by IP/domain/key is correct and aligns with the refactor.
165-165: Persist click to Redis viarecordClickCache.set
Caching the recorded click for IP-based deduplication for one hour is implemented as intended.
170-170: UseclickIdCache:prefix for short-term click data
Storing click details under the new namespace with a 5-minute TTL matches the other updated cache key conventions.
|
@coderabbitai any breaking changes? |
|
Tip For best results, initiate chat on the files or code changes. @devkiran No, there don't appear to be any breaking changes in this PR. Here's why: Non-breaking refactoring:
Backward compatibility measures:
Minor consideration:
The changes appear to be a well-executed internal refactoring with proper backward compatibility considerations. |
Summary by CodeRabbit