Forum Discussion

sullysnack's avatar
sullysnack
Khoros Alumni (Retired)
9 years ago

Caching API objects


As part of our effort to reduce API calls and improve overall page load performance, recently we stumbled on this…
http://community.lithium.com/t5/Developers-Knowledge-Base/Return-FreeMarker-objects-as-JSON-or-XML-strings/ta-p/184087
That's good stuff. Didn't notice any mention of it in 15.12 release notes. Anyway, we can take advantage.

 

We're familiar with caching strings using either appcache, usercache or http.session. Say in one custom component we make a v2 query which returns an array of 25 messages, we're assuming we can call apiv2.toJson to get a string representation of the messages, then we can cache the string somewhere. During the same page load but in some other custom component we assume we can ?eval the string back into an array.

 

Is the resulting evaluated object an exact replica of the original object which was returned from the v2 query? We're worried that some field types won't be exactly the same, and that we'll need to carefully update the rest of our old code to accommodate slight differences. When time allows I will investigate.

 

Before we re-factor custom code to support something like above, we're wondering if there's any way to cache an object or an array returned from an API call natively, without having to convert the object or array into a json string first (and of course, later, the string back into an object or array).

 

Consider a single Forum Topic page load. The topic has 200+ replies, but the current page 1 load will show the original post and 29 replies. In a custom component in the Forum Message quilt, for each reply we'll make an API call to see what star-rating the current user has given the reply (if any). Can the result of that API call be cached natively for use in any other custom component which could be loaded during this page load, or for use in endpoints which may be loaded some short time after the page has loaded?

 

Assume the cached information is destroyed or recreated at next page load.

 

The goal here is to cache data from API calls for use in Page initialization, in any custom component or in any endpoint, but without having to pass the object between components. In some cases we're dealing with Lithium black box components which as far as we know don't let us pass extra objects. In some cases we're not exactly sure which 29 replies are going to appear on this page load, and we wouldn't want to query for all 200 replies of the topic before some other component will process the relevant 29 replies one at a time. Also, we see no way to pass a native object queried in Page initialization to any other custom components.

 

Right now we're caching json strings in http.session but we're worried that repeated calls to get and set session storage during a single page load will bog down the server at that level of the stack – even though we may have reduced load at the Lithium v1 & v2 API level of the stack.

 

We don't think that appcache or usercache fit the bill, since documentation states their cache information is shared across all anonymous sessions. We're interested in caching information returned from API calls only for the lifetime of a single page load for the current single user / visitor. So our eyes turned to http.session. Would you warn against this method?

 

Thank you,
Dave

 

 

No RepliesBe the first to reply