Refactor cache-header handling and config, create NonMemoryCachingBaseService, rewrite [flip] (#2360)
There's a lot going on in this PR, though it's all interdependent, so the only way I can see to break it up into smaller pieces would be serially.
1. I completely refactored the functions for managing cache headers. These have been added to `services/cache-headers.js`, and in some ways set the stage for the rest of this PR.
- There are ample higher-level test of the functionality via `request-handler`. Refactoring these tests was deferred. Cache headers were previously dealt with in three places:
- `request-handler.js`, for the dynamic badges. This function now calls `setCacheHeaders`.
- `base-static.js`, for the static badges. This method now calls the wordy `serverHasBeenUpSinceResourceCached` and `setCacheHeadersForStaticResource`.
- The bitFlip badge in `server.js`. 👈 This is what set all this in motion. This badge has been refactored to a new-style service based on a new `NoncachingBaseService` which does not use the Shields in-memory cache that the dynamic badges user.
- I'm open to clearer names for `NoncachingBaseService`, which is kind of terrible. Absent alternatives, I wrote a short essay of clarification in the docstring. 😝
2. In the process of writing `NoncachingBaseService`, I discovered it takes several lines of code to instantiate and invoke a service. These would be duplicated in three or four places in production code, and in lots and lots of tests. I kept the line that goes from regex to namedParams (for reasons) and moved the rest into a static method called `invoke()`, which instantiates and invokes the service. This _replaced_ the instance method `invokeHandler`.
- I gently reworked the unit tests to use `invoke` instead of `invokeHandler`– generally for the better.
- I made a small change to `BaseStatic`. Now it invokes `handle()` async as the dynamic badges do. This way it could use `BaseService.invoke()`.
3. There was logic in `request-handler` for processing environment variables, validating them, and setting defaults. This could have been lifted whole-hog to `services/cache-headers.js`, though I didn't do that. Instead I moved it to `server-config.js`. Ideally `server-config` is the only module that should access `process.env`. This puts the defaults and config validation in one place, decouples the config schema from the entire rest of the application, and significantly simplifies our ability to test different configs, particularly on small units of code. (We were doing this well enough before in `request-handler.spec`, though it required mutating the environment, which was kludgy.) Some of the `request-handler` tests could be rewritten at a higher level, with lower-level data-driven tests directly against `cache-headers`.
This commit is contained in:
@@ -11,6 +11,7 @@ const analytics = require('./analytics')
|
||||
const { makeSend } = require('./result-sender')
|
||||
const queryString = require('query-string')
|
||||
const { Inaccessible } = require('../services/errors')
|
||||
const { setCacheHeaders } = require('../services/cache-headers')
|
||||
|
||||
// We avoid calling the vendor's server for computation of the information in a
|
||||
// number of badges.
|
||||
@@ -57,23 +58,6 @@ function flattenQueryParams(queryParams) {
|
||||
return Array.from(union).sort()
|
||||
}
|
||||
|
||||
function getBadgeMaxAge(handlerOptions, queryParams) {
|
||||
let maxAge = isInt(process.env.BADGE_MAX_AGE_SECONDS)
|
||||
? parseInt(process.env.BADGE_MAX_AGE_SECONDS)
|
||||
: 120
|
||||
if (handlerOptions.cacheLength) {
|
||||
// If we've set a more specific cache length for this badge (or category),
|
||||
// use that instead of env.BADGE_MAX_AGE_SECONDS.
|
||||
maxAge = handlerOptions.cacheLength
|
||||
}
|
||||
if (isInt(queryParams.maxAge) && parseInt(queryParams.maxAge) > maxAge) {
|
||||
// Only allow queryParams.maxAge to override the default if it is greater
|
||||
// than the default.
|
||||
maxAge = parseInt(queryParams.maxAge)
|
||||
}
|
||||
return maxAge
|
||||
}
|
||||
|
||||
// handlerOptions can contain:
|
||||
// - handler: The service's request handler function
|
||||
// - queryParams: An array of the field names of any custom query parameters
|
||||
@@ -89,31 +73,23 @@ function getBadgeMaxAge(handlerOptions, queryParams) {
|
||||
// (undesirable and hard to debug).
|
||||
//
|
||||
// Pass just the handler function as shorthand.
|
||||
function handleRequest(handlerOptions) {
|
||||
function handleRequest(cacheHeaderConfig, handlerOptions) {
|
||||
if (typeof handlerOptions === 'function') {
|
||||
handlerOptions = { handler: handlerOptions }
|
||||
}
|
||||
|
||||
const allowedKeys = flattenQueryParams(handlerOptions.queryParams)
|
||||
const { cacheLength: serviceCacheLengthSeconds } = handlerOptions
|
||||
|
||||
return (queryParams, match, end, ask) => {
|
||||
const reqTime = new Date()
|
||||
|
||||
const maxAge = getBadgeMaxAge(handlerOptions, queryParams)
|
||||
// send both Cache-Control max-age and Expires
|
||||
// in case the client implements HTTP/1.0 but not HTTP/1.1
|
||||
if (maxAge === 0) {
|
||||
ask.res.setHeader('Cache-Control', 'no-cache, no-store, must-revalidate')
|
||||
ask.res.setHeader('Expires', reqTime.toGMTString())
|
||||
} else {
|
||||
ask.res.setHeader('Cache-Control', `max-age=${maxAge}`)
|
||||
ask.res.setHeader(
|
||||
'Expires',
|
||||
new Date(+reqTime + maxAge * 1000).toGMTString()
|
||||
)
|
||||
}
|
||||
|
||||
ask.res.setHeader('Date', reqTime.toGMTString())
|
||||
setCacheHeaders({
|
||||
cacheHeaderConfig,
|
||||
serviceCacheLengthSeconds,
|
||||
queryParams,
|
||||
res: ask.res,
|
||||
})
|
||||
|
||||
analytics.noteRequest(queryParams, match)
|
||||
|
||||
@@ -269,14 +245,9 @@ function clearRequestCache() {
|
||||
requestCache.clear()
|
||||
}
|
||||
|
||||
function isInt(number) {
|
||||
return number !== undefined && /^[0-9]+$/.test(number)
|
||||
}
|
||||
|
||||
module.exports = {
|
||||
handleRequest,
|
||||
clearRequestCache,
|
||||
// Expose for testing.
|
||||
_requestCache: requestCache,
|
||||
getBadgeMaxAge,
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user