Cache the list of sites in the site-menu.

[Trek Hopton]

Instead of fetching the list of sites every time from the datastore, VidGrind could cache the list for speedier loading times.

[Alan Noble]

Note that the datastore layer already performs caching for Site entities for Get/Put/Delete requests but not GetAll. Implementing caching for the latter at the datastore layer is non-trivial. Therefore, my recommendation is for VidGrind to implement caching at the client level, that nonetheless takes advantage of underlying caching for per-entity requests.

‌

[Trek Hopton]

I see. We should have a client cache expiry to make sure the site names get updated. I can’t think of another way of validating the client cache. Unless we immediately show the cached site names, then fetch the actual sites in the background and update if needed. Site names should rarely be changed though so I think a cache expiry is fine. If the user really wants to see the new names instantly, they can clear their browser cache. We could also clear the browser cache when a user renames a site, so they can see their renamed site immediately.

[Alan Noble]

Note that the datastore layer caching mechanism already refreshes the cache with every Put, Delete or DeleteMulti. This mechanism works well when there is a single instance of VidGrind (the dominant case at present). We will need a cache expiry mechanism though, when we have multiple instances of VidGrind, as one instance could do a Put while another instance continues to use a stale cached value.