Shields has long had an in-memory cache with some complex logic for determining when the cached values are used and when they are flushed. At the time this was implemented, squeezing cache performance was helpful since there was no downstream cache. For years now we've used Cloudflare as a CDN, so trying to cache onboard is less useful than before. Furthermore, since the cache is very small and only used in fairly restrictive ways, it probably has very little impact on performance.
One of the tests for the Maintenance service that was added when the service was refactored is failing
`AssertionError: message mismatch: expected 'no! (as of 2018)' to equal 'stale (as of 2019)'`
I believe the test was added in an attempt to cover the one of the code paths, but that original test would only pass a couple months out of the year.
Testing those paths with the original implementation would have required a lot of stubbing clocks/timers, so instead I refactored the code a bit. I removed the flaky live/service test, and added some unit tests instead (which made more sense to me since this service badge doesn't hit a live endpoint)
Fixes#2876 with @paulmelnikow's suggestion
Moved imports of `ServiceTester` and `createServiceTester` to a separate file so that dev dependencies are not imported by service classes.
Continue to implement #2698:
- Add `core/base-service/index.js` (but hold off on moving the things it imports)
- Add shortcuts in `services/index.js` for Base*Service, errors, and deprecatedService. This file will be streamlined later to avoid cluttering it with rarely used bits.
- Apply consistent ordering of imports and use of `module.exports` in testers.
- Remove some renaming of imports.
- Remove obsolete tests here and there.
The term “url” is overloaded in services, to refer to the Shields route and also the API URL. Calling the Shields URL a “route” is on the whole more descriptive, and makes it clearer and more obvious which one of these we’re talking about. It’s a small thing, though seems like an improvement.
We have a few functions called `buildUrl`. I’ve renamed them to `buildRoute` when they refer to routes, and left them as `buildUrl` when they refer to API URLs.
I included a minor style tweak and some formatting cleanup in `TUTORIAL.md`.
This is consistent with what we're pretty much already doing, and saves us from making the request during code review.
These were all autofixed and most of them seem easier to read. Some in the legacy services should be rewritten in more legible forms during refactor (ie using intermediate variables, or using request’s qs option). There are some in helper functions and elsewhere that should get rewritten separately. I don't want to change them in this PR because the changes will get lost in this diff, though we could identify them here and fix them before or just after.
all-badge-examples is a common cause of merge conflicts. It’s difficult to adjust the badge categorization in that file – or to understand the diff – because it requires moving a block from one point to another. It’s much easier to edit a badge’s category in one place.
This starts the process of breaking up what’s left of that file, following up on the work from #1931. New-style services can only be in one category, which means legacy service examples have to be split along category lines. I split out separate legacy service classes where I could do so easily, leaving behind the ones which require more work, for one reason or another.
