We are evaluating Zoom phones as an alternative to our current phone system. As part of the analysis we’ve been tasked to investigate how we can integrate the Zoom api with our current React web application framework.
The most notable discrepancy is the change is regarding pagination. The proposed deprecation will impact our applications ability to use the Zoom API without performance, technical and design implications.
Our web framework uses pagination and filters to limit requests; improving user experience and application performance. There are several html components and api calls that utilize an offset and limit to calculate the page number (in zoom api terms page_number and page_count) and a total record count to show how many pages there are.
This change has made it incredibly difficult for us to implement pagination, as the framework validates that a page offset, limit and total count on list requests. It would also remove the ability for a user to select a specific page or to navigate back a page without caching whatever requests are made and navigating around the expiration of said tokens.
Hi @wattry.virginia.tech
Thanks for reaching out to the Zoom Developer Forum and sorry for the late reply
I am happy to help here!
Are you still having issues handling pagination in your integration?
Hi @wattry.virginia.tech
I am just checking in with you again, to see if you need some assistance/guidance here.
See if you can smuggle the next page token in place of the page offset and lock the page size at the same value for the entire session, then only allow paging forward. The only improvements Zoom could make to support these scenarios is to offer a previous page token alongside the next page token (which would enable backwards pagination) and remove the expiration of these tokens.
I can sympathize with this challenge — I was lucky to work with a database administrator that was very sensitive to performance concerns and required us to use pagination tokens instead of page numbers, so these bad page number habits were shaken out of us. We always had to pass all of the neighboring row’s sort field values and the desired direction back to the database to receive the next (page size) rows in that direction, which allows the database to never have to capture the entire result set. This meant that from a user interface perspective, we could only offer next and previous page navigation (we had to ask for (page size + 1) rows and discard the extra row so we would know whether to offer a pagination link at all), or jump to the first or last records. As you paginated, any row additions or removals were immediately visible, so ending up with uneven page sizes when you reached either end was common, even if you simply went back and forth between, say, the first two pages. On the bright side, there was no expiration for pagination, which is friendly for users.
Hi Elisa,
I lost track of the post after 10 days or so trying to come up with an alternative solution.
It’s not an issue so much as a question for the Zoom api team. Have they considered the implications on users or is our use case is so marginal that I’m speaking out of turn?
As @MultiplayerSession has pointed out there are some functional limitations with the new changes. We’d lose the ability to navigate a result set backwards, only forwards. We’d have to make, non-trivial, changes to our UI framework to enable simple forward pagination.
We could potentially find a middle ground with a previous token though short of that we’d have to store everything in our browser cache and still change our framework.
Can anyone on the api team perhaps point us to a rationale or a best practice document so we can understand how we can adapt?
Thanks for sharing more details with me @wattry.virginia.tech
I totally understand what you are saying and I will make sure to reach out to our API team and share with them your feedback and will come back to you with more information.
Thanks again!
Elisa
It’s been 19 days can we please get a response on this?
In summary, they’re moving towards keyset pagination / seek method for pagination. Further reading:
Hi @wattry.virginia.tech
Thank you for your patience on this and @MultiplayerSession thank you so much for your continued effort in assisting the Developer Community.
I did not find any internal docs or more details about this change in our pagination and I understand how this can be a blocker for you, but the next_page_token was introduced last year and it is part of our continued effort to mitigate resource abuse.
Cheers,
Elisa
Hi Elisa, I really appreciate the materials @MultiplayerSession has provided. I think understanding what is going on in the greater community is very helpful. So much appreciated @MultiplayerSession.
In the context of the performance and reliability benefits of the keyset pagination I can understand the change. Though in terms of paginating backwards, this is still an issue that will persist. Is it possible that we could get a feature request to add the ability to paginate backwards? We may be able to interface with the web framework we use to update the pagination requirements they force, given we are able to provide a justifiable use case.
Thanks
Hi @wattry.virginia.tech
Thanks for understanding this issue and yes, I can go ahead and create a feature request on your behalf for this pagination requirement you are looking for.
1 Like