badges
Deleting old redirectors
We've currently got around 70 redirectors in our services, which map from one badge URL to another. These are useful to improve a badge path (e.g. making it more consistent or more flexible) whilst maintaining backwards compatibility for existing users.
Until now, we have never touched them, virtually all redirectors have been kept around since their creation. As a consequence, their number is growing over time.
I personally don't like the idea of being required to hold on to something permanently. Additionally, having all these redirectors does incur a small performance hit: the way ScoutCamp works is that it adds all badge URLs to an array, and for an incoming badge request, tries to match it against an element by iterating through said array. Having a bunch of extra elements in the array will make that operation marginally slower. There's also a maintenance overhead aspect to consider.
Let's face it, we're not going to get big performance improvements nor save ourselves a ton of work by removing a few redirectors. But every little helps.
Worth noting that some redirectors have pretty much no usage, deleting them is a net win:
I suggest we formalise a rule for deletion. Something time based like the one year period we follow for our deprecated services is probably not a good idea, as some redirectors have heavy usage and will need to be kept around for many years. But perhaps one of these rules would strike a good balance and ensure minimal impact on users:
- Delete redirectors that have had e.g. less than 100 usages in a 24 hour period.
- Delete redirectors that have less than 1% of the traffic of the new URL they redirect to.
Let me know what you think!
That's a good insight, i think it's a bit more delicate then deprecated badges as they are still functional.
Regarding the rule, I don't think there is an optimal way to do this, if our goal here is performance we can use an or for the two conditions: redirects<100 or redirects<0.01*destination rule, so we catch the small fish that will hurt the least number of users while giving the best brakeage-to-performance ratio while also using the relative rule to help migrating more popular badge's redirects in a reasonable amount of time.
I think its best if we combine these rules with a minimum amount for a redirection of 1 year, to offer better stability.
I do have a concert from the perspective of a user, We should probably show a warning for badges being redirected to encourage users to update and avoid sudden breakage, this is beneficial for both us and our users. Also if we just delete them users might get confused, should we add a stage for showing a deprecation message? I think we should do at least one of the above when we retire a redirection, might not have to be both.
Agreed on the one year minimum for keeping a redirector.
Perhaps we could do what we did in #8671, i.e. rendering a badge that points to a GitHub issue (https://github.com/badges/shields/blob/3b85bf89d7364f98c3774d60fe322021cc2ce3e4/services/github/github-workflow-status.service.js#L18) that helps users with the migration. That issue has so many PRs pointing to it that I can't load all items, but it look like the bulk of upgrades happened in the first few months of us breaking the URL.
So our process could be along the following lines:
- Create redirector for whatever reason.
- Once the redirector is at least a year old, if one of the absolute or the relative rule is met, create an issue with migration instructions.
- Deprecate the badge with the badge's message pointing to the issue.
- After a year, the badge can completely be deleted as per our usual deprecation policy.
Looks good, as you already started work on the redirectors docs, can you update this into our docs at #11524 ?
@LitoMore any strong opinions on this before I move forward with the proposal in linked PR?
