Implement Pagination for /view endpoint

[RusseII]

/view endpoint currently returns ALL of the past updates. I plan to use this bot for YEARS which means every single day the data returned by /view will increase and increase

[Geczy]

Be careful not to use limit&skip methods in mongodb to add this

BAD :

https://www.npmjs.com/package/mongoose-paginate-v2 https://github.com/aravindnc/mongoose-paginate-v2/blob/master/src/index.js#L177

GOOD :

https://github.com/mixmaxhq/mongo-cursor-pagination

API Pagination is typically implemented one of two different ways:

Offset-based paging. This is traditional paging where skip and limit parameters are passed on the url (or some variation such as page_num and count). The API would return the results and some indication of whether there is a next page, such as has_more on the response. An issue with this approach is that it assumes a static data set; if collection changes while querying, then results in pages will shift and the response will be wrong.

Cursor-based paging. An improved way of paging where an API passes back a "cursor" (an opaque string) to tell the caller where to query the next or previous pages. The cursor is usually passed using query parameters next and previous. It's implementation is typically more performant that skip/limit because it can jump to any page without traversing all the records. It also handles records being added or removed because it doesn't use fixed offsets.

[RusseII]

https://swr.vercel.app/docs/pagination

Sent from my iPhone

On Jul 10, 2021, at 09:31, Matt @.***> wrote:

 Be careful not to use limit&skip methods in mongodb to add this

BAD :

https://www.npmjs.com/package/mongoose-paginate-v2 https://github.com/aravindnc/mongoose-paginate-v2/blob/master/src/index.js#L177

GOOD :

https://github.com/mixmaxhq/mongo-cursor-pagination

API Pagination is typically implemented one of two different ways:

Offset-based paging. This is traditional paging where skip and limit parameters are passed on the url (or some variation such as page_num and count). The API would return the results and some indication of whether there is a next page, such as has_more on the response. An issue with this approach is that it assumes a static data set; if collection changes while querying, then results in pages will shift and the response will be wrong.

Cursor-based paging. An improved way of paging where an API passes back a "cursor" (an opaque string) to tell the caller where to query the next or previous pages. The cursor is usually passed using query parameters next and previous. It's implementation is typically more performant that skip/limit because it can jump to any page without traversing all the records. It also handles records being added or removed because it doesn't use fixed offsets.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Geczy]

I think we want a separate page for each user ? Kind of like a blog site tbh

[RusseII]

I think we want a separate page for each user ? Kind of like a blog site tbh

I like having them all together. My main use case would be to visit the site 1x a day after 11 to view everyones updates (and another time to post my update, and ideally a way to respond to other peoples updates)

[Geczy]

So is the current collapse view annoying? Would it be better to have just one table showing the last update for each person? And then maybe expand each row to show more updates from them

[RusseII]

So is the current collapse view annoying?

Yes

Would it be better to have just one table showing the last update for each person?

Yes

And then maybe expand each row to show more updates from them

Yes

[Geczy]

I fixed the current view to show latest 1 update, now just need to make the "more" button work to show the remaining updates

[Geczy]

site is deprioritized