Design UI caching architecture

Description

The purpose of this ticket is to design a standardized architecture for caching data on the UI.

Currently, the parts of the UI that do the caching encounters the following problems:

  • not standardized

  • code is duplicated

  • implementation is spread (single solution requires adding changes in multiple places)

There are two main approached at the moment:

Acceptance Criteria

  • Page on the Confluence (?) describing a centralized mechanism for caching data on the UI.

    • workflow diagrams

  • Tickets for implementing the design.

  • Tickets for updating current caching mechanisms.

Questions

  • When to fetch data?

    • after login - if necessary

    • when they are required

  • How to refresh data?

    • non-versioning on login

    • versioning never because they don’t change

  • Should we keep some of the data between sessions?

    • non-user specific data should be always stored

  • What about eTags? Should we add support for them? Should we extend backend to support them more widely?

    • How does storing large dataset in shared dictionary look/work like?

    • Consider what is available on the backend as well

 

Status

Assignee

Nikodem Graczewski

Reporter

Nikodem Graczewski

Labels

Story Points

5

Time tracking

64h

Sprint

None

Fix versions

Priority

Major
Configure