[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Web API Library Cache Design Question
- From: Choonster TheMage <choonster.2010@...>
- Date: Fri, 12 Apr 2013 15:57:47 +1000
I'm working on a library that provides an easy interface to a REST API
serving JSON[1]. The smallest results are about 1,000 characters
long[2] and the largest are about 684,000 characters long[3].
I'm caching the results so not every call to the methods result in a
full GET request being sent.
Currently I store the decoded table in the cache table and return a
shallow proxy table that has its __index pointing to the top level
result table. This prevents any modification of the top-level table,
but any tables nested in it are unprotected.
I can think of three different storage methods for the results to
prevent any modification of the cached value:
1) Use recursive proxies instead of shallow ones, i.e. access to a
nested table returns a proxy instead of the real table. This results
in a small overhead for each table lookup.
2) Deep copy the cached table and return the copy. This is simple, but
it may take a long time to copy the table version of link 3. This
results in a high initial overhead with raw table lookups for all
nested tables instead of the overhead of __index lookups.
3) Store the JSON string and decode it each time. This also has a high
initial overhead with raw table lookups (I'm not sure how much
overhead compared to the deep copy).
Does anyone have any opinions on these?
Regards,
Choonster
[1] http://blizzard.github.io/api-wow-docs/.
[2] https://gist.github.com/Choonster/5369708#file-itemdata-json
[3] https://gist.github.com/Choonster/5369708#file-auctiondata-json