[Feature Request] server side pagination and filtering

[thefcraft]

Problem

The current implementation fetches the entire dataset from the backend and applies pagination and filtering on the client side. While this works for small datasets, it does not scale well as the number of bookmarks grows.

Proposed Solution

Update the existing TanStack React Table setup to support server-side pagination and filtering. Instead of loading all records at once, the backend should handle:

• Pagination (page size, page index)
• Filtering (search, column filters, etc.)
• Sorting

The frontend would then request only the required slice of data based on the table state.

Benefits

Significantly improved performance for large datasets
Reduced memory and network usage on the client
Better scalability, enabling users to create and manage very large bookmark collections

Notes

TanStack React Table already supports server-side mode, so this should be achievable with minimal changes to the table configuration and API contracts.

[thefcraft]

@denho i don't know php but gemini does so here is the session code, if you want you may look it.

i already tested the frontend part in my fastapi implementation it works [may have to fix the Untagged and all items logic but apart from that it mostly works some modification may needed]

jules_session_5992635085355691914.zip

[denho]

@thefcraft Thank you for the suggestion and the code example. I’ve considered server-side pagination for large datasets before, but so far I haven’t noticed any performance issues with collections that I tested (up to ~10k items). According to the TanStack Table docs, it can handle "100,000 rows or more with decent performance for client-side filtering, sorting, pagination, and grouping"

Another factor is that we plan to support offline usage, which would require storing all bookmarks in the client memory and support pagination, sorting, and filtering on the frontend.

Have you personally experienced any slowness or performance degradation with your collection? If so, what was its size and what device were you using?

[thefcraft]

@thefcraft Thank you for the suggestion and the code example. I’ve considered server-side pagination for large datasets before, but so far I haven’t noticed any performance issues with collections that I tested (up to ~10k items). According to the TanStack Table docs, it can handle "100,000 rows or more with decent performance for client-side filtering, sorting, pagination, and grouping"

Another factor is that we plan to support offline usage, which would require storing all bookmarks in the client memory and support pagination, sorting, and filtering on the frontend.

Have you personally experienced any slowness or performance degradation with your collection? If so, what was its size and what device were you using?

I mean i don't notice any performance issue but i suggested server side logic for scalability. This maybe overkill but this reduces server resources utilization like bandwidth if we have large users on single server.

I suggested this because i thought this may be helpful in future.

[denho]

Thank you, @thefcraft.

Let’s keep this issue open for the time being to let others to share their input. This will also give us a chance to gather any further considerations or arguments that might support the case for implementing server-side pagination and filtering.

[abhigyantrips]

one of the reasons i prefer faved over other bookmarkers is because of the "instant search". i don't have to wait for the results to load in. that being said, i'm currently only at around 213 bookmarks, so i can see it getting heavy with the different OG images and stuff.

i've currently been looking at faved as a personal bookmarker, not a collective service. could it be possible to look into it as an env argument to toggle? i can see it being more complex to develop.

[denho]

Making server-side filtering optional (e.g. via an env toggle) sounds nice in theory, but in practice it would add quite a bit of complexity to the codebase and maintenance. It essentially means supporting two different search modes (client + server), keeping behavior consistent between them, and handling edge cases for both paths — which can get tricky pretty quickly.

Faved is definitely positioned more as a personal bookmark manager right now, as you mentioned, and the UX priority is to keep that instant, no-wait feel. Even with hundreds or a few thousand bookmarks, the current client-side approach should remain fast in normal usage.

If performance starts to degrade at larger scales, that’s something I’d rather address with optimizations (e.g. indexing, lazy loading, caching strategies) rather than introducing a parallel server-side mode.