Performance degradation with large expense histories (>4 MB tRPC responses)

[IXRaijin]

Describe the bug
Performance degrades significantly when viewing a friend or group with a large expense history.

My dataset currently contains approximately 3,593 active expenses. When loading the affected friend or group, SplitPro generates very large tRPC responses and logs the following Next.js warning:

API response for /api/trpc/user.getFriend,expense.getExpensesWithFriend,user.getBalancesWithFriend?... exceeds 4MB. API Routes are meant to respond quickly.

The same warning occurs for expense.getGroupExpenses.

Firefox DevTools shows approximately 12.4 MB of XHR traffic when loading the affected page.

To Reproduce
Steps to reproduce the behavior:

1. Have a friend/group with a large expense history (approximately 3,500+ expenses in my case).
2. Open the friend or group in SplitPro.
3. Wait for the expense history to load.
4. Notice the slow page load.
5. Check the SplitPro logs and observe that the expense.getExpensesWithFriend or expense.getGroupExpenses tRPC response exceeds 4 MB.

Expected behavior
Large expense histories should remain reasonably responsive.

Ideally, the expense history could be paginated, cursor-based, or loaded incrementally rather than returning several thousand expenses in a single API response.

Screenshots
I can provide Firefox Network/Timing screenshots if useful.

App version
2.1.3

Desktop (please complete the following information):

• OS: Windows 11
• Browser: Firefox
• Version: 155

Smartphone (please complete the following information):

• N/A

Additional context
The application is self-hosted and uses PostgreSQL 17.

I tested a representative PostgreSQL query for the affected expense history:

EXPLAIN (ANALYZE, BUFFERS)
SELECT e.*
FROM "Expense" e
JOIN "ExpenseParticipant" ep ON ep."expenseId" = e.id
WHERE ep."userId" = 2
AND e."deletedAt" IS NULL;

The query returned approximately 3,593 rows with an execution time of roughly 6 ms.

This suggests that basic PostgreSQL retrieval itself is fast, while the performance issue may be related to constructing, serializing, transferring, and/or rendering the large API response.

The repeated warnings include:

expense.getExpensesWithFriend:
API response for /api/trpc/user.getFriend,expense.getExpensesWithFriend,user.getBalancesWithFriend?... exceeds 4MB.

expense.getGroupExpenses:
API response for /api/trpc/group.getGroupDetails,group.getGroupTotals,expense.getGroupExpenses?... exceeds 4MB.

Given the response size, would pagination/infinite scrolling or otherwise limiting the number of expenses returned by these endpoints be appropriate?

[krokosik]

Yeah, the infinite scroll/pagination for expense lists and activity page has been on my TODO list for a while now, but have scarce time to work on SP recently and I have not hit your number of expenses yet 😅