perf(home): batch Site card analytics with and without MVs - #1211
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (11)
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review. 📝 WalkthroughWalkthroughThe change adds organization-scoped analytics requests, batched site-card endpoints, shared query builders, and homepage rendering. It validates access and time windows, supports standard and lite modes, and adds client, server, and ClickHouse coverage. ChangesSite Card Analytics
Priority: ➖ Normal Estimated code review effort: 4 (Complex) | ~60 minutes Change: Refactor Sequence Diagram(s)sequenceDiagram
participant Homepage
participant useGetSiteCards
participant OrganizationAPI
participant ClickHouse
Homepage->>useGetSiteCards: request site metrics
useGetSiteCards->>OrganizationAPI: POST organization site-cards endpoint
OrganizationAPI->>ClickHouse: execute totals and series queries
ClickHouse-->>OrganizationAPI: return aggregate rows
OrganizationAPI-->>useGetSiteCards: return SiteCardsResponse
useGetSiteCards-->>Homepage: render batched site cards
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
A homepage with 20 Site cards can start 60 analytics requests, repeatedly reading the same data and competing for ClickHouse resources. Both standard and lite deployments now send one organization-scoped request per page. The backend runs two queries concurrently: current/comparison sessions and users, plus session-only sparklines without the unused event JOIN and other chart metrics.
Standard deployments query
eventsdirectly, with one scan per query. User identity is resolved per Site, session, and period using the existing overview definition, so identification in the current period cannot rewrite previous-period users; overlapping comparison windows also work. Lite deployments use their existing materialized views. No migration or new configuration is required.The batch accepts at most 20 Sites and checks organization ownership and caller access before querying. Cards share the response, show totals independently of viewport visibility, and fetch settings only when opened. Cache keys include the endpoint, organization, Site IDs, both periods, timezone, and bucket. Lite mode retains the existing fallback for exact datetime ranges and unbounded hourly charts. Standard mode batches these too; its all-time charts also place zero-session activity buckets at their actual time instead of the old FULL JOIN's incorrect 1970 timestamp.
Validation:
NEXT_PUBLIC_LITE_DASHBOARD=false npm run build -- --webpack.CLICKHOUSE_TEST_URLwithout creating tables. Earlier lite checks covered another 73 fixture SELECTs.For 20 Sites over the last 24 hours plus the previous 24-hour comparison, the raw totals query took 1.35–1.41 seconds and sparklines took 0.27–0.28 seconds in two runs. Earlier lite repeat runs took 1.28–2.13 seconds for totals and 0.19 seconds for sparklines, with an initial totals outlier of 18.17 seconds. These are query timings without a query-result cache, not an end-to-end browser benchmark; a consistent 10× homepage improvement still needs measurement after deployment.
Existing repository check limitations: the default Turbopack build cannot resolve the existing
@rybbit/sharedimport inuseOrgApiKeys.tsin this local checkout.npm run linthas an empty ESLint configuration, scans generated.nextfiles, and does not lint the TypeScript source. Neither configuration is changed here.Summary by CodeRabbit