Dynamic cache length overriding

[paulmelnikow]

For the Endpoint badge: #2473.

request-handler.js is such a bear. I’m looking forward to being able to rewrite it when the service refactor is done.

[shields-ci]

	Messages
📖	✨ Thanks for your contribution to Shields, @paulmelnikow!

Generated by 🚫 dangerJS against a0b4a5e

[paulmelnikow]

Updated for consistency with same-named variable above.

[chris48s]

OK, so having spent some time reading over this, I think I can see what's going on:

You've got defaultCacheLengthSeconds which can be overridden by serviceDefaultCacheLengthSeconds (either by category or on a badge-by-badge basis). Then in turn that can be overridden by serviceOverrideCacheLengthSeconds (which we expect to be used only in the dynamic badge) but only if serviceOverrideCacheLengthSeconds is longer than serviceDefaultCacheLengthSeconds and then the maxAge query param can also override both of those but again only if maxAge is longer.

..yeah? And it also looks correct.

I can see how we've ended up at this point (one edge-case at a time) and I get that its difficult to have a single place in the codebase that encodes all of that logic because we want to introduce each of those params at different layers of the application for different reasons (also I accept that I've contributed some of this complexity). This set of rules is going to be non-obvious to a contributor who isn't already deeply familiar with the codebase and "how long will this badge be cached for" may be a hard question to answer or reason about.

I think as time goes on and we get rid of the rest of the legacy services, we can ditch 2 of these layers, but until that time this set of rules seems like it could really use some docs to explain that chain of overrides. Does that sound reasonable?

[paulmelnikow]

Yes, that is a great summary of what is happening.

Maybe we can just paste it into request-handler.js for now.

The more I understand the code in request-handler.js, the clearer it is that HTTP requests don't need to be intertwined with caching and timeouts. I'm wondering, if the legacy service rewrite is going to take a while longer, if we should go ahead build its replacement. Then we could shim it in reverse: re-implement LegacyService.register to invoke registerLegacyRouteHandler with a made-up sendBadge function that is compatible enough with those services.

[chris48s]

seems fair enough

[paulmelnikow]

Thanks for reviewing!

[shields-deployment]

This pull request was merged to master branch. This change is now waiting for deployment, which will usually happen within a few days. Stay tuned by joining our #ops channel on Discord!

After deployment, changes are copied to gh-pages branch: