Whenever possible render the MR Diffs from a client-side cache unless MR ID is outdated
Important note: This issue is somewhat of a placeholder, very likely we'll have to move this to an Epic and break down into issues.
Context
In the context of the newly formed Performance Round TablesCode Review, this idea came to light:
@patrickbajao's comment:
I'm thinking of something related to this on diffs specifically on displaying the HEAD diff...
The idea is to cache the diff on the client with an ID. Before requesting batch diffs from the backend, frontend will first check if there's already a cached diff with the same ID. If so, display the cached diff. If not, request batch diffs and cache. This way, we can reduce making requests to backend when client already has the data.
The HEAD diff has an unique
id
and every time there's a change in the HEAD diff (e.g. changes are done on target branch, new changes are made on the MR) we generate a new one so theid
would change. I think we can use that as the ID. We don't expose this at the moment but I think it can be exposed as part of themerge_request_diff
property ofdiffs_metadata.json
.Another idea for the ID is the fingerprint of a diff which is related to the idea that @kerrizor shared in #378954 (closed).
This is just an idea though and I'm not sure about the feasibility of it yet.
Outdated details
Proposal (outdated)
- Calculate an ID/Fingerprint for each MR HEAD comparison
- Provide that ID/Fingerprint to the frontend on each MR render
- Frontend checks whether that ID/Fingerprint is equal to the one cached in the browser
- If yes, render from cached copy
- If not, fetch from the server updated data.
- Render
- Replace cache
Roughly speaking... this plan should be validated and potentially changed accordingly.
Questions (outdated)
- What client side cache would we use? IndexedDb? Local Storage?
- Is this much better than the current ETag/client side cache?
- Can/Should we leverage the Service Worker or the plan described in the 1-App setup [Working Title] - Snappy GL (&8859) ?
- Should we worry about privacy when a member has been removed from a project but the diff is still cached on their browser? If so, can we mitigate this?
- ...
Plan (actual)
After cache key has been rolled out, we can now ensure the Frontend uses that parameter to leverage the http caching mechanism.