Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
...
HoldingsIQ doesn't provide endpoints to paginate titles' resources currently:
Possible solutions:
Solution | mod-kb-ebsco work | Adventages | Disadventages |
---|---|---|---|
pagination on HoldingsIQ side (f.e. /{custId}/titles/{titleId}/resources api with pagination) | Update api in mod-kb-ebsco accordingly | Ability to paginate, no additional requests or excessive logic | Needs work to be done from ebsco side |
pagination only on mod-kb-ebsco side | Implement caching of HoldingsIQ' title response(with some ttl and invalidation on PUT/POST/DELETE requests) Add pagination parameters to current '/titles/{titleId}?include=resources' api Paginate over cached data(if cache exists, otherwise get data from HoldingsIQ, then cache response and return desired page) | No need for work from ebsco side | Additional database calls on every api call (check cache exists, save cache, query cache when paginate) Additional database calls on other api calls (when updating title then cache must be deleted) Also there should be a scheduler which will check cache ttl in background and expire cache for all tenants (additional application resources for scheduler and additional load on database for ttl check and expiration) Note: this approach will not save us from situation when there are too much resources in a title and they cannot fit into http response (because pagination is absent on holdingsIQ side and we will not be able to get all resources from holdingsIQ which returns all resources for a title on each api call) |
It was decided to implement pagination only on front-end side as this solution will not have side effects for performance and will add only ux. Story was created:
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|