Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODKBEKBJ-591

...

HoldingsIQ doesn't provide endpoints to paginate titles' resources currently:

Possible solutions:

Solutionmod-kb-ebsco workAdventagesDisadventages
pagination on HoldingsIQ side (f.e. /{custId}/titles/{titleId}/resources api with pagination)Update api in mod-kb-ebsco accordinglyAbility to paginate, no additional requests or excessive logicNeeds 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
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUIEH-1258
.