google spreadsheets still hitting rate limit even with caching

[kapil1garg]

when the SprintCache is empty, the sprint log parser will still run into rate limits trying to parse all sprints in DTR (such as if queried by an orchestration script).

See if the quota can be raised, and/or retry when request fails

[kapil1garg]

On second thought, this might be timeouts. Need to investigate

[kapil1garg]

a temporary fix for this is for the studio API on start-up to populate all the data caches by itself (rather than waiting for a request to come in). then when queries are made, only the sprint logs where the data has changed will need to be fetched since everything else can be retrieved from cache (which is much faster)

[kapil1garg]

PR #16 includes a hotfix for this solution. One limitation of using the google-spreadsheet wrapper package is its limited flexibility in how to read data from a sheet (must make a query for each worksheet). A more permanent solution might be to switch to Google's own APIs which support reading an entire spreadsheet in 1 call which would reduce our calls to 1 for every project instead of 5-6 (see here), and also supports exponential backoff so that requests are automatically re-tried.

seems like there's also a simple implementation as part of google-spreadsheet that is implemented, but not in the latest package yet.