API caching solutions

[Mattias Lagergren]

I'd like to see if we can get going a discussion of a somewhat hidden, yet powerful feature of the ftrack-python-api: the possibility to setup your own caching. During our 2015 London user group meeting The Mill shared some of their experiences on this topic.

Are there anyone else out there looking at caching. How are you dealing with cache invalidations, what solutions are you using for the cache - e.g. Redis or something else? Statistics on cache hit/miss and % of improvements is also interesting. Please come and share your experiences with the Community!

[instinct-vfx]

I would love to get some experiences on this! We are looking into it. So far we based our plans mostly around what the mill showed but i am eager to hear other shops' thoughts!

[Martin Pengelly-Phillips]

We are improving our setup and have been thinking about better cache invalidation.

Currently, we have to reproduce, through introspection, server side logic in order to invalidate linked entities efficiently. We have been discussing with the ftrack team having more information exposed through the API to make this less error prone. An alternative that was discussed was having dumb cache invalidation listeners and ftrack would simply emit all the appropriate update events for any action (e.g if a user deleted, invalidate 'author' reference on specific entities). However, as some of the logic occurs in the database, the ftrack team were not sure they would be able to emit the events correctly.