Paginate set contributions instead of embedding them - #40
Open
jckbtchr-vv wants to merge 1 commit into
Open
Conversation
GET /v1/set-submissions/:uuid returned 4.8MB for a busy set. 98% of that
was participationImages: 3,213 rows, each preloading its image, its
creator and the creator's pfp. Without them the same response is 99KB.
The client already virtualises the contributions grid, so this was never
a render cost. It was transfer, paid by every visitor before the page
could paint, and again on the frontend's refresh interval.
participationImages is now only embedded when asked for
(?includes[]=participationImages), so existing consumers can opt back in
unchanged. New alongside it:
GET /v1/set-submissions/:uuid/participation
page, limit, filter, sort. filter[creatorAddress] pages a single
artist's contributions, which is what grouping the grid by artist
needs.
GET /v1/set-submissions/:uuid/participation-stats
contribution and contributor counts, so a client can size the list
without fetching it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
GET /v1/set-submissions/:uuidreturns 5,036,026 bytes (4.8MB) for 11x11.98% of that is
participationImages: 3,213 rows, each preloading its image, its creator, and the creator's pfp. Strip them and the same response is 99KB.The client already virtualises the contributions grid, so this was never a render cost. It is transfer, paid by every visitor before the page can paint, and again on the frontend's refresh interval.
The change
participationImagesis now embedded only when asked for, using the existingincludesconvention fromOpepenController:This is non-breaking by default. Any consumer that needs them can opt back in with no other change.
Two routes added alongside, following the pagination pattern in
AccountsController(page/limit/filter/sort):filter[creatorAddress]pages a single artist's contributions. That is the piece we need to group the contributions grid by artist rather than showing one flat wall of 3,213 tiles.participation-statsreturns contribution and contributor counts so a client can size the list without fetching it.Sequencing
The frontend currently reads
participationImagesoff the submission response, so this should deploy before the frontend switches to the new route. Nothing breaks in the meantime: the field is simply absent unless requested, and the frontend change is a separate PR.Not verified
I could not run the test suite. There is no
.envin the repo and no local Postgres, sonode ace testfails at boot on a missingAPP_URL. The functional specs undertests/functional/cover this controller area, and contributor/co-creator code has had three PRs in the last few weeks, so please run them before merging.Typecheck passes with no new errors (the one
@visualizevalue/img-griderror is present on cleanmaintoo).