Support Comment Pagination #6158

Closed
opened 2021-06-02 07:01:22 +02:00 by tiger5226 · 1 comment
tiger5226 commented 2021-06-02 07:01:22 +02:00 (Migrated from github.com)

Currently we have numerous claims with more comments than the max supported page size (200) of the comment server. The UI when the comments were added avoided implementing the pagination. As a work around the UI team had made the page size 99,000 comments. Once we added live streams this became a massive load as thousands of people made the call with thousands of comments. We had to limit the server temporarily.

We continue to try to work around this but what we really need is for the API to be used correctly for proper scalability.

The comment.List API has the following paramters:

// ListArgs arguments for the comment.List rpc call
type ListArgs struct {
	ClaimID       *string `json:"claim_id"`
	AuthorClaimID *string `json:"author_claim_id"`
	ParentID      *string `json:"parent_id"`
	Page          int     `json:"page"`
	PageSize      int     `json:"page_size"`
	TopLevel      bool    `json:"top_level"`
	Hidden        bool    `json:"hidden"`
}

Page and PageSize can be used for pagination. The default order of comments is by timestamp, descending. We can add alternative sorting options to the API as well for taking care of different lists of comments. For example, there is a section for "Controversial". This is a good example of an extension to the API.

Currently we have numerous claims with more comments than the max supported page size (200) of the comment server. The UI when the comments were added avoided implementing the pagination. As a work around the UI team had made the page size 99,000 comments. Once we added live streams this became a massive load as thousands of people made the call with thousands of comments. We had to limit the server temporarily. We continue to try to work around this but what we really need is for the API to be used correctly for proper scalability. The `comment.List` API has the following paramters: ```golang // ListArgs arguments for the comment.List rpc call type ListArgs struct { ClaimID *string `json:"claim_id"` AuthorClaimID *string `json:"author_claim_id"` ParentID *string `json:"parent_id"` Page int `json:"page"` PageSize int `json:"page_size"` TopLevel bool `json:"top_level"` Hidden bool `json:"hidden"` } ``` `Page` and `PageSize` can be used for pagination. The default order of comments is by timestamp, descending. We can add alternative sorting options to the API as well for taking care of different lists of comments. For example, there is a section for "Controversial". This is a good example of an extension to the API.
tzarebczan commented 2021-06-02 19:46:06 +02:00 (Migrated from github.com)

We'd definitely need support for the sorting, which would need to now be computed on the commentron side vs app side.

What do we want to do with replies? Have you tested to see if replies are treated correctly - regardless of timestamp, a comment that has replies should return it's whole thread, even if it goes over the page size (otherwise this may be a strange scenario where the app has to load the new page mid reply, and it may not know it needs to).

We'd definitely need support for the sorting, which would need to now be computed on the commentron side vs app side. What do we want to do with replies? Have you tested to see if replies are treated correctly - regardless of timestamp, a comment that has replies should return it's whole thread, even if it goes over the page size (otherwise this may be a strange scenario where the app has to load the new page mid reply, and it may not know it needs to).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbry-desktop#6158
No description provided.