WIP, Nick Reid (Deactivated) I'm just starting the brainstorming here.
Date
Attendees
Goals
- Discuss UI caching, what it means, performance v cost
- Approach with Reference Data and Snapshotting which will have the best performance
- UI as an App and last mile connectivity
Brainstorm
An idea that's been floating around is to cache large Reference Data lists, Orderables and associated entities, on the client-side device (browser or someday even an app perhaps):
- A "working document" we'll define as a Requisition or an Order. It's something that a workflow is built around. For such working documents, we know they will need the details of Orderables, Facilities, Programs, etc.
- Such data usually first is defined in Reference Data, however it's not always guranteed to be immutable - ie it may change.
- The change is usually slow - Product lists, facilities, etc aren't updated daily or usually not even weekly. Annual cycles or more common SOP.
- When every working document comes over the network with this reference data, the network payload quickly outstrips the reasonable bandwidth.
Could the UI store a list of this Reference Data, which it downloads over the network infrequently?
Option A: Reference Data is Immutable
With this option, any change to something in Reference Data (e.g. an Orderable, TradeItem, Facility, etc) would be treated as:
- mark existing record as archived
- create new record (with new UUID), linking back to previous record (if any)
The benefit to this is that if you've downloaded, or store a reference to any Reference Data UUID, you never have to update it. You may have to check if it's archived, and then optionally go and retrieve the new object.
For the UI applied to Requisitions (presume similar to other working documents):
- Download the full list of FTAP WITH eagerly fetched Orderables to Programs (5000 items x 3 deep)
- With a HEAD request to the respective endpoints, discover if this list has changed, if it has, download the new list (infrequent).
- Any change means this list gets bigger and bigger. If everything changed every year, after 3 years this list is 15,000 items x 3 deep.
Option B: Working Document Snapshot is cached
The working document's Service takes a full snapshot of the Reference Data it uses (Orderables, facilities, etc). With this option, Reference Data is mutable, it may change at any time. The Requisition Service (the working documents service) would take a snapshot of that Reference Data, and store it locally forever for all of the Requisition's it has.
For the UI applied to Requisitions:
- Download the Requisition's Snapshot cache of Line Item Orderables (X items where X is the number of FTAP (Orderables x Program x Type) that have been used in all requisitions, columns targetted to the ones the Requisition document needs)
- When a Requisition is initiated, the list from Ref Data FTAP is fetched, and Requisition's Snapshot of FTAP (down through the Orderable defintion) is placed in the snapshot "dictionary". If nothing has changed, nothing needs to be added.
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|