* Explicitly set the Redis database number used for rate limiting
* Switch to using ioredis as the Redis client for rate limiting
* Install ioredis-mock as a primary dependency
* Create a Redis BasicAccessor class and tests
* Switch rendered page caching to use Redis for storage
* Add support for additional Redis SET options like TTLs
* Remove currently unused methods
* Rename redis-accessors/basic to redis-accessor and remove extra fluff
* Change default behavior for cache setting to throw if an error occurs
Add option allowSetFailures to facilitate graceful failures
* Allow SET failures to fail gracefully for the rendered page cache
* Remove as-yet unneeded serialization options from RedisAccessor
* Move Redis client construction into RedisAccessor constructor, just pass in databaseNumber as option
* Remove rendered-page-cache in favor of direct RedisAccessor use
* Add tests for RedisAccessor constructor param validations
* Eliminate one roundtrip to Redis for the cached HTML existence check
Are we fast yet?
* Set a rendered page cache TTL of 24 hours
Make Rate Limiter Aggressive on statuses > 400
This is based on the hypothesis that the Node
application shouldn't be getting hit with a large number of requests in
general thanks to Fastly and certainly shouldn't be getting hit with a
large number of requests that have status codes greater than 400 unless
a user or bot is trying to guess random URLs and as a result. For
example, see this IP address that caused some site issues on October 3
Co-authored-by: Chiedo <chiedo@users.noreply.github.com>
Co-authored-by: Jason Etcovitch <jasonetco@github.com>
