feat(axios): implement etag functionality

[seaerchin]

Problem

Currently, Isomer uses a huge amount of tokens due to not caching. This leads to scaling issue, where our github token limits are quickly reached and users are unable to access the CMS.

Closes IS-172

Solution

1. use an external package axios-cache-interceptor to utilise ETags for cache. See here for info on etags.
   • note that this is using in memory storage. the implications are that: we could potentially have some requests that could be cached but are not (current ETag value is 1 -> user A edits -> ETag value now 2 -> other instance doesn't knows -> queries from other instance -> ETag value updated)
   • potential for stale reads - github will tell us if the old etag value is outdated or not (ie, return 200) but the package uses the cache-control header to control freshness (which is good). because github's header sets max-age=60, the package will internally use the old value for 60s.

Tests

1. first, add a console.log for remainingRequests into respHandler for AxiosInstance.ts, so that we know how much requests are remaining
2. next, issue a GET request to the e2e-test-repo's homepage (curl --request GET \ --url http://localhost:8081/v2/sites/e2e-test-repo/homepage)
3. observe the # of requests remaining.
4. repeat steps 2-3; the # of requests remaining should be unchanged
5. make an edit on the homepage
6. repeat steps 2-3, the # of requests should be unchanged if it's less than a minute
7. update the page again
8. do steps 2-3, the request should succeed

New dependencies:

• axios-cache-interceptor : interceptor for axios to use etags. the current backing storage is in memory.

Deploy notes

1. axios got upgraded from 0.21.x to 0.25.0
   • list of breaking changes here
   • went through most of them, mostly typing changes.
2. had to use 0.9.2 as a minimum for axios-cache-interceptor
   • see compat chart here
   • this is because of 2 reasons - ETag functionality only added in 0.6 + their import for object-code is an outdated one, which doesn't get fixed till 0.9.2.

[kishore03109]

[Non-nit]

I think the stale time should be something that we should explicitly define in our application. If we monitor that our token usage is getting too high, it would be a lot easier for us to tweak this number to reduce the number of calls. Thoughts?

[seaerchin]

[Non-nit]

I think the stale time should be something that we should explicitly define in our application. If we monitor that our token usage is getting too high, it would be a lot easier for us to tweak this number to reduce the number of calls. Thoughts?

to clarify, you mean the max age of 60s? i think this number is explicitly given by github as a header for to let us know how long to cache a request before revalidation. i think the use case of allowing it in code to be able to control it is fair but we should add this as a follow up if required rather than having it as a first pass, because the default that github sends might already be enough! do take note that this refetch is only triggered on etag change - ie, past 60s, file is unchanged, github will return a 304 without consuming token usage

wdyt?

[kishore03109]

to clarify, you mean the max age of 60s? i think this number is explicitly given by github as a header for to let us know how long to cache a request before revalidation. i think the use case of allowing it in code to be able to control it is fair but we should add this as a follow up if required rather than having it as a first pass, because the default that github sends might already be enough! do take note that this refetch is only triggered on etag change - ie, past 60s, file is unchanged, github will return a 304 without consuming token usage

makes sense to me, we can monitor if we actually want the ability to toggle the time taken for invalidation in the future then