GitLab Version - Internal Endpoint
What does this MR do and why?
Sets up endpoint for !74830 (merged)
Creates an internal endpoint to fetch data form the external endpoint implemented here: https://gitlab.com/gitlab-services/version-gitlab-com/-/merge_requests/621
Creates an internal endpoint: /admin/version_check.json
We need a safe way to make an asynchronous call to the external version check endpoint. This way we can protect from any sort of DDOS/high volume causing an instance to load slowly while trying to fetch this data. This internal endpoint will allow us to do just that via a AJAX request from Javascript. That will be implemented in the follow up MR linked above.
This endpoint has two levels of caching since it will exist in the Header Nav and have a high volume of usage for any instance that is used by Admin users.
- Client Caching
- The controller uses
expires_in
to cache the response on a users browser for 1 minute.
- The controller uses
- ReactiveCaching
- The service file uses
ReactiveCaching
to store the external endpoint's data on the instance to avoid numerous external calls.
- The service file uses
There is no/low risk of an invalid cache here as the ReactiveCache uses the Version as the key. So if the instance is upgraded, the version will change and thus the cache will begin using a new key and clear the old one.
Screenshots or screen recordings
Not Logged/Non Admin | Empty Cache | Valid Cache |
---|---|---|
How to set up and validate locally
Important: Since version_check uses ReactiveCaching you will need to "warm the cache up" when testing. This will mean that your first hit on your instance will be null
. In the background the cache will be fetched/created async. So after reloading you should see the badge appear.
Important: You must be an Admin user to hit this endpoint
- Navigate to
/admin/version_check.json
while logged in as an admin user - Ensure the response is null (cache is empty)
- Navigate to
/admin/version_check.json
again while logged in as an admin user - Ensure a response is given now that the cache is populated.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #295266 (closed)