Pagination for area and climb media#449
Conversation
ee137c9 to
20bde8b
Compare
The problem is that staging doesn't have images. I think deploying to prod is fine though since nobody will be using the new endpoints yet |
20bde8b to
9324990
Compare
|
I finished writing tests for the new endpoints. I haven't modified the existing |
|
@glassbead0 we talked about creating a new GraphQL field, eg |
I added new fields to the area and climb API's. There is now a new field under I see an |
|
I've added a test for the mediaPagination within the existing I'm happy to let this sit until then if consensus is that we should add a test before merging, but seems like adding a more comprehensive test of the climb endpoint (along with several other endpoints that dont' have integration tests), should maybe be separate tasks? What are your thoughts @vnugent |




Add query endpoints for
areaMediaPaginationandclimbMediaPaginationFor each query, the uuid is required (
climbUuidorareaUuid), and the other pagination optionsafter,first, andmaxFilesReturns the uuid (climb or area), and a
mediaConnection, with the same structure as thegetUserMediaPaginationendpoint, including totalItems.Technical details:
For queuing areas/climbs with lots of media (eg, the entire US), this should be efficient and fairly fast.
We only query the number of media objects + 1 requested with
first(defaults to 6), so we aren't loading all the media objects into memory. We usecountDocumentsto efficiently get the totalItems.Testing performance locally is difficult as i don't currently have an efficient way to add lots and lots of media.
will it be possible to deploy this to staging and performance test there before pushing to production?
@vnugent @Vichy97