Implement cache strategy

[pwalsh]

I've played with various cache implementations quite bait over the course of development, but currently, we have not settled on the appropriate strategy.

The data model is highly relational and in parts, complex (templates > nodes + sheets > items), and is not well suited for serving read queries. Part of the design is that, because these datasets change rarely, that all reads will be from cache (redis).

One option that is very efficient is to use query set caching. This is great if we have a set of queries that we know will be called time and time again.

Queryset caching does not cover the Open Budgets use case well, however, because we expect API calls with a range of params, and these are all distinct queries.

The desired behaviour is:

• DB is only for writes
• All (99%) of reads for "sheets" and "entities" objects should come directly from cache
• perhaps each object should be written to cache on write (destroy old on update)
• Every object we want to cache uses UUID for primary key, so we can simply use that for the cache key
• object's cache does not need to invalidate until that object is updated

[pwalsh]

the only problematic endpoints, for current performance, are:

• /api/v1/sheets/items/
• /api/v1/templates/nodes/

The 'items' endpoint is critical. This should be the focus, and then we'll move on once we have an implementation for this.

[BeOleg]

For some reason debug toolbar and model translation don't like each other, any idea how this could be resolved?. Costed me a few hours so far :(

[pwalsh]

Hi @BeOleg I see they don't work together, and I have no idea how to resolve it. I've in the middle of of making some changes to the items endpoint now for the upcoming launch with google. So, wait a few days.

Did you make any progress with caching until now?

[pwalsh]

@BeOleg I'm re-assigning this issue to myself - I'm doing some refactoring to this API endpoint & the caching as part of the contract between HaSadna and Google.

[pwalsh]

boom.