[Date Prev][Date Next][Thread Prev][Thread Next]
- 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. The smallest results are about 1,000 characters
long and the largest are about 684,000 characters long.
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?