Arvados

h1. Workbench responsiveness

Notes on Workbench performance/caching from brainstorming meeting 2024-09-04

* Currently the store is our cache, and it caches individual objects (key is UUID)

** When opening an object in a new tab, it might be easy to use postMessage to pass the current store contents to the new tab to speed things up

** Each data explorer has its own store key, so (for example) we store "page of project listing" rather than "page 1 of project A listing with filters xyz"

** We could start using the store to cache list responses (key is request URL with all params?)

** We could pre-fetch and cache the next page of a listing before the user even clicks the "next page" button

** Currently the store grows indefinitely, so if we use it more, we'll need an eviction strategy

** We could save timestamps in the store so we don't re-fetch on every page view when navigating back and forth quickly

* In theory, web workers could implement an HTTP cache shared between tabs

** Lisa has some experience with web workers that didn't go well (ended up bailing), but would be willing to look into it again

** Tom hasn't tried it but remembers reading that the mechanics of installing/updating the web worker code is non-trivial

** Would presumably be disabled for most of the test suite

* Collection file listings are slow because XML decoding is slow, and we don't use the store to cache them

** We could start caching the (decoded) listings in the store

** We could add a JSON format option to keep-web to skip XML encoding+decoding entirely (Workbench doesn't need to support arbitrary WebDAV servers, after all)