Cache vulnerability endpoints with a service worker on the group security dashboard
Problem to solve
This might seem similar to #58298 (moved). That's because it is. See this comment for context.
The loading speed of the group security dashboard starts to suffer when there's a lot of projects with within them. This is mostly down to the fetching of the history and vulnerabilities endpoints. Regular caching could cause problems for us as these vulnerabilities are subject to changes.
Target audience
This will impact anyone who uses the group security dashboard(s), but will mainly help the users that look at the same ones frequently:
-
Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
-
Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
Further details
We are adding a service worker in !23578 (closed) but haven't utilised the most powerful aspect of it yet, caching.
We could cache history.json
, and vulnerabilities.json
so they're all set and ready when you re-visit that page.
We'd have to make a subsequent call to check for the updates but it would improve initial loading speeds.
This is simple enough for the service worker but requires our cache management to be spot on so we're not showing outdated data.
Proposal
Use the existing service worker to cache the endpoints that are requested by the user. On subsequent visits, we can serve the endpoints from the cache initially then wait for the request to complete and use and cache the updated ones.
See this video for an explanation of how it would work with the discussions on merge requests (includes audio)
Screen_Recording_2019-02-27_at_16.22.29
Permissions and Security
We might have to look into the security implications of storing the result of these endpoints on the user's machine. I'm pretty sure it's all secure and fine, but we should be certain.
Documentation
We shouldn't need documentation as (if done correctly) no one will notice this has happened other than the speed increase.
What does success look like, and how can we measure that?
Success is if we get a speed boost in loading speeds for secondary visits of the group security dashboard. I'm not sure how well our performance metrics will measure this so this might be something we need to look into