apicache vs cache-manager vs cacheable-request vs lru-cache vs memory-cache vs node-cache

Choosing the Right Caching Strategy for Node.js Applications

These six packages offer different approaches to caching in Node.js environments, ranging from simple in-memory storage to HTTP-specific caching layers. lru-cache provides a fundamental Least Recently Used algorithm implementation, while node-cache and memory-cache offer straightforward in-memory key-value storage with TTL support. cache-manager acts as a wrapper allowing multiple cache stores (memory, Redis, etc.) with a unified API. apicache focuses specifically on Express middleware for caching HTTP responses, and cacheable-request adds HTTP caching semantics to request clients. Each serves distinct architectural needs from low-level data structures to high-level HTTP response caching.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package	Downloads	Stars	Size	Issues	Publish	License
Package	Downloads	Stars	Size	Issues	Publish	License
apicache	0	1,249	-	63	4 years ago	MIT
cache-manager	0	1,959	52.2 kB	0	2 months ago	MIT
cacheable-request	0	1,959	79.5 kB	0	2 months ago	MIT
lru-cache	0	5,835	841 kB	4	19 days ago	BlueOak-1.0.0
memory-cache	0	1,600	-	32	9 years ago	BSD-2-Clause
node-cache	0	2,375	-	77	6 years ago	MIT

Choosing the Right Caching Strategy for Node.js Applications

Caching is essential for building performant Node.js applications, but picking the wrong tool can lead to memory leaks, stale data, or unnecessary complexity. The six packages we are comparing — apicache, cache-manager, cacheable-request, lru-cache, memory-cache, and node-cache — each solve different parts of the caching puzzle. Some focus on HTTP responses, others on data structures, and some on abstraction layers. Let's break down how they work and when to use each one.

🏗️ Core Architecture: What Each Package Actually Does

lru-cache is a pure data structure implementation.

It provides a Least Recently Used eviction algorithm.
No built-in TTL (time-to-live) in older versions, though newer versions support it.
You manage the cache lifecycle yourself.

// lru-cache: Basic usage
import { LRUCache } from 'lru-cache';

const cache = new LRUCache({
  max: 500,
  ttl: 1000 * 60 * 5 // 5 minutes
});

cache.set('key', 'value');
const value = cache.get('key');

node-cache is a full in-memory cache with TTL and events.

Built on top of basic object storage with cleanup intervals.
Supports key patterns, cloning, and event hooks.
Runs entirely in process memory.

// node-cache: With TTL and events
import NodeCache from 'node-cache';

const cache = new NodeCache({ stdTTL: 100 });

cache.on('expired', (key, value) => {
  console.log(`Key ${key} expired`);
});

cache.set('key', 'value', 200);
const value = cache.get('key');

memory-cache is a minimal in-memory store.

Very simple API with basic TTL support.
No event system or advanced features.
Good for quick prototyping.

// memory-cache: Simple set/get
import cache from 'memory-cache';

cache.put('key', 'value', 1000 * 60); // 1 minute
const value = cache.get('key');
cache.del('key');

cache-manager is an abstraction layer over multiple stores.

Wraps different cache backends (memory, Redis, etc.) with one API.
Supports multi-caching (writing to multiple stores at once).
Allows swapping implementations without code changes.

// cache-manager: With memory store
import cacheManager from 'cache-manager';
import memoryStore from 'cache-manager-remember';

const cache = cacheManager.caching({
  store: memoryStore,
  ttl: 60,
  max: 100
});

await cache.set('key', 'value');
const value = await cache.get('key');

apicache is Express middleware for HTTP response caching.

Caches entire HTTP responses automatically.
Configurable by status code, URL, and TTL.
⚠️ Deprecated: No longer actively maintained as of 2023.

// apicache: Express middleware
import apicache from 'apicache';
import express from 'express';

const app = express();
app.use(apicache.middleware);

app.get('/api/data', apicache.middleware('5 minutes'), (req, res) => {
  res.json({ data: 'cached response' });
});

cacheable-request adds HTTP caching to request clients.

Wraps HTTP clients to respect cache headers.
Stores responses based on HTTP semantics (ETag, Last-Modified).
Works with got, request, or native http.

// cacheable-request: HTTP caching
import CacheableRequest from 'cacheable-request';
import http from 'http';

const cacheableRequest = new CacheableRequest(http.request);

const req = cacheableRequest('https://api.example.com/data', {
  cacheOptions: { cacheTtl: 1000 * 60 * 5 }
});

req.on('response', (res) => {
  console.log('Status:', res.statusCode);
});

⏱️ TTL and Expiration Handling

How each package handles time-based expiration varies significantly.

lru-cache uses TTL per entry in newer versions (v7+). Older versions relied on LRU eviction only.
node-cache has global and per-key TTL with automatic cleanup intervals.
memory-cache supports per-key TTL but no global cleanup configuration.
cache-manager delegates TTL to the underlying store implementation.
apicache uses TTL for HTTP response validity.
cacheable-request respects HTTP Cache-Control headers plus optional overrides.

// lru-cache: Per-entry TTL
const cache = new LRUCache({ ttl: 5000 });
cache.set('key', 'value', 5000); // 5 seconds

// node-cache: Global and per-key TTL
const cache = new NodeCache({ stdTTL: 60 });
cache.set('key', 'value', 120); // Overrides global to 2 minutes

// memory-cache: Per-key TTL only
cache.put('key', 'value', 60000); // 60 seconds

// cache-manager: Store-dependent TTL
await cache.set('key', 'value', 60); // 60 seconds

// apicache: Middleware TTL string
app.get('/api', apicache.middleware('10 minutes'), handler);

// cacheable-request: HTTP header based
const req = cacheableRequest(url, { cacheOptions: { cacheTtl: 60000 } });

🔄 Eviction Strategies: LRU vs TTL vs Manual

Understanding how items leave the cache is critical for memory management.

lru-cache evicts based on access order when max size is reached. Least recently used items go first.
node-cache evicts based on TTL expiration with periodic cleanup checks.
memory-cache evicts based on TTL expiration during get operations.
cache-manager depends on the store — memory uses LRU or TTL, Redis uses TTL.
apicache evicts based on TTL and memory limits.
cacheable-request evicts based on HTTP cache headers and storage limits.

// lru-cache: LRU eviction when max reached
const cache = new LRUCache({ max: 100 });
// When 101st item added, oldest accessed item is removed

// node-cache: TTL-based cleanup
const cache = new NodeCache({ checkperiod: 60 }); // Check every 60 seconds

// memory-cache: Lazy cleanup on get
// Items removed when accessed after expiration

// cache-manager: Configurable per store
const cache = cacheManager.caching({ store: 'memory', max: 100 });

// apicache: Memory limit configuration
apicache.options({ debug: true, defaultDuration: 3600000 });

// cacheable-request: Storage-based eviction
const cacheableRequest = new CacheableRequest(http.request, { cacheAdapter: new Keyv() });

🌐 HTTP vs Data Caching: Different Use Cases

Some packages cache HTTP responses, others cache application data.

apicache and cacheable-request focus on HTTP layer caching.
lru-cache, node-cache, memory-cache, and cache-manager focus on application data.

// apicache: HTTP response caching
app.get('/users', apicache.middleware('5 minutes'), getUsers);

// cacheable-request: HTTP client caching
const getData = () => cacheableRequest('https://api.example.com/users');

// node-cache: Application data caching
const users = await cache.get('users');
if (!users) {
  const data = await db.query('SELECT * FROM users');
  cache.set('users', data);
}

// lru-cache: Application data with LRU
const cache = new LRUCache({ max: 1000 });
cache.set('userId', userData);

// memory-cache: Simple data caching
cache.put('session', sessionData, 3600000);

// cache-manager: Unified data caching
await cache.set('config', configData, 300);

⚠️ Maintenance Status and Production Readiness

Not all packages are equally maintained for production use.

apicache — ⚠️ No longer actively maintained. Last significant update was in 2021. Consider alternatives like route-cache or custom middleware for new projects.
memory-cache — ⚠️ Minimal maintenance. Works but lacks modern features and active development.
lru-cache — ✅ Actively maintained. Widely used as a dependency by many major packages.
node-cache — ✅ Stable and maintained. Good for in-process caching needs.
cache-manager — ✅ Actively maintained. Regular updates and community support.
cacheable-request — ✅ Maintained. Works well with modern HTTP clients.

// For new projects, prefer maintained packages
import { LRUCache } from 'lru-cache'; // ✅ Recommended
import NodeCache from 'node-cache'; // ✅ Recommended
import cacheManager from 'cache-manager'; // ✅ Recommended

// Avoid for new production projects
import apicache from 'apicache'; // ⚠️ Deprecated
import cache from 'memory-cache'; // ⚠️ Minimal maintenance

📊 Feature Comparison Table

Feature	`lru-cache`	`node-cache`	`memory-cache`	`cache-manager`	`apicache`	`cacheable-request`
Type	Data Structure	In-Memory Cache	In-Memory Cache	Cache Abstraction	HTTP Middleware	HTTP Client Wrapper
TTL Support	✅ (v7+)	✅	✅	✅ (Store-dependent)	✅	✅ (HTTP Headers)
LRU Eviction	✅	❌	❌	✅ (Memory store)	✅	❌
Events/Hooks	❌	✅	❌	✅	✅	✅
Multi-Store	❌	❌	❌	✅	❌	❌
HTTP Aware	❌	❌	❌	❌	✅	✅
Maintenance	✅ Active	✅ Stable	⚠️ Minimal	✅ Active	⚠️ Deprecated	✅ Active
Best For	Low-level caching	In-process data	Simple prototyping	Flexible backends	Express response caching	External API calls

🎯 Real-World Selection Guide

Scenario 1: Caching Database Query Results

You need to cache query results in memory with automatic expiration.

✅ Best choice: node-cache or lru-cache
Why? You need TTL and reliable eviction without external dependencies.

// Using node-cache for query results
const cache = new NodeCache({ stdTTL: 300 });

async function getUser(id) {
  const cached = cache.get(`user:${id}`);
  if (cached) return cached;
  
  const user = await db.users.findById(id);
  cache.set(`user:${id}`, user);
  return user;
}

Scenario 2: Caching External API Responses

You make frequent calls to third-party APIs and want to respect their cache headers.

✅ Best choice: cacheable-request
Why? It handles ETag, Last-Modified, and Cache-Control automatically.

// Using cacheable-request for external APIs
const cacheableRequest = new CacheableRequest(http.request);

async function fetchExternalData(url) {
  return new Promise((resolve, reject) => {
    const req = cacheableRequest(url);
    req.on('response', res => {
      // Handle response with caching applied
    });
    req.end();
  });
}

Scenario 3: Express API Response Caching

You want to cache entire HTTP responses for GET endpoints.

✅ Best choice: Custom middleware or cache-manager with Express
Why? apicache is deprecated. Build custom logic or use maintained alternatives.

// Custom Express caching with cache-manager
app.get('/api/data', async (req, res) => {
  const cached = await cache.get(req.url);
  if (cached) return res.json(cached);
  
  const data = await fetchData();
  await cache.set(req.url, data, 60);
  res.json(data);
});

Scenario 4: Multi-Environment Caching Strategy

You need to switch between memory (development) and Redis (production) without code changes.

✅ Best choice: cache-manager
Why? Unified API allows swapping stores via configuration.

// cache-manager with configurable store
const store = process.env.NODE_ENV === 'production' ? 'redis' : 'memory';

const cache = cacheManager.caching({
  store: store,
  ttl: 60,
  redis: { host: 'localhost', port: 6379 }
});

Scenario 5: High-Performance In-Memory Cache

You need maximum performance for a hot path with strict memory limits.

✅ Best choice: lru-cache
Why? Highly optimized, minimal overhead, precise control over memory usage.

// lru-cache for performance-critical paths
const cache = new LRUCache({
  max: 10000,
  ttl: 60000,
  updateAgeOnGet: true
});

💡 Final Recommendations

For most applications, start with node-cache for simple in-memory needs or cache-manager if you anticipate needing Redis later. Both are well-maintained and offer good developer experience.

For HTTP-specific caching, use cacheable-request for external API calls. Avoid apicache in new projects due to its deprecated status — instead, build custom Express middleware using cache-manager or a Redis-backed solution.

For low-level optimization, lru-cache is the gold standard. It is used by many major packages internally and provides the best performance for LRU-based eviction.

Avoid memory-cache for production systems requiring long-term support. While simple, it lacks the features and maintenance commitment of node-cache or cache-manager.

Remember that caching adds complexity — always measure the performance impact and ensure your cache invalidation strategy matches your data consistency requirements. A well-configured cache can speed up your application significantly, but a poorly managed one can lead to stale data and hard-to-debug issues.

How to Choose: apicache vs cache-manager vs cacheable-request vs lru-cache vs memory-cache vs node-cache

apicache:
Choose apicache if you need quick HTTP response caching for Express applications without writing custom logic. It works as middleware to cache entire route responses based on status codes and TTL. However, note that this package is no longer actively maintained, so evaluate newer alternatives for production systems requiring long-term support.
cache-manager:
Choose cache-manager when you need flexibility to swap cache backends (memory, Redis, file system) without changing your application code. It provides a unified API across different stores and supports clustering. Ideal for applications that might need to scale from simple in-memory caching to distributed Redis caching later.
cacheable-request:
Choose cacheable-request when you need HTTP-level caching that respects standard cache headers (ETag, Last-Modified, Cache-Control). It wraps HTTP clients like got or request to automatically handle caching based on server responses. Best for applications making many external API calls where you want to respect upstream cache policies.
lru-cache:
Choose lru-cache when you need a performant, low-level LRU data structure without extra features like TTL or clustering. It is highly optimized and widely used as a dependency by other caching libraries. Perfect for scenarios where you need fine-grained control over cache eviction based on access patterns rather than time.
memory-cache:
Choose memory-cache for simple, lightweight in-memory caching with basic TTL support in small Node.js applications. It has a very simple API but lacks advanced features like clustering or multiple stores. Consider this only for development or small-scale projects where complexity must be minimized.
node-cache:
Choose node-cache when you need a reliable in-memory cache with TTL, event hooks, and key pattern matching in a single Node.js process. It offers more features than memory-cache while remaining simple to use. Suitable for applications that need periodic cleanup and cache event monitoring without external dependencies.

Popular Comparisons

apicache

cache-manager

cacheable-request

lru-cache

memory-cache

node-cache

README for apicache

A simple API response caching middleware for Express/Node using plain-english durations.

Supports Redis or built-in memory engine with auto-clearing.

Why?

Because route-caching of simple data/responses should ALSO be simple.

Usage

To use, simply inject the middleware (example: apicache.middleware('5 minutes', [optionalMiddlewareToggle])) into your routes. Everything else is automagic.

Cache a route

import express from 'express'
import apicache from 'apicache'

let app = express()
let cache = apicache.middleware

app.get('/api/collection/:id?', cache('5 minutes'), (req, res) => {
  // do some work... this will only occur once per 5 minutes
  res.json({ foo: 'bar' })
})

Cache all routes

let cache = apicache.middleware

app.use(cache('5 minutes'))

app.get('/will-be-cached', (req, res) => {
  res.json({ success: true })
})

Use with Redis

import express from 'express'
import apicache from 'apicache'
import redis from 'redis'

let app = express()

// if redisClient option is defined, apicache will use redis client
// instead of built-in memory store
let cacheWithRedis = apicache.options({ redisClient: redis.createClient() }).middleware

app.get('/will-be-cached', cacheWithRedis('5 minutes'), (req, res) => {
  res.json({ success: true })
})

Cache grouping and manual controls

import apicache from 'apicache'
let cache = apicache.middleware

app.use(cache('5 minutes'))

// routes are automatically added to index, but may be further added
// to groups for quick deleting of collections
app.get('/api/:collection/:item?', (req, res) => {
  req.apicacheGroup = req.params.collection
  res.json({ success: true })
})

// add route to display cache performance (courtesy of @killdash9)
app.get('/api/cache/performance', (req, res) => {
  res.json(apicache.getPerformance())
})

// add route to display cache index
app.get('/api/cache/index', (req, res) => {
  res.json(apicache.getIndex())
})

// add route to manually clear target/group
app.get('/api/cache/clear/:target?', (req, res) => {
  res.json(apicache.clear(req.params.target))
})

/*

GET /api/foo/bar --> caches entry at /api/foo/bar and adds a group called 'foo' to index
GET /api/cache/index --> displays index
GET /api/cache/clear/foo --> clears all cached entries for 'foo' group/collection

*/

Use with middleware toggle for fine control

// higher-order function returns false for responses of other status codes (e.g. 403, 404, 500, etc)
const onlyStatus200 = (req, res) => res.statusCode === 200

const cacheSuccesses = cache('5 minutes', onlyStatus200)

app.get('/api/missing', cacheSuccesses, (req, res) => {
  res.status(404).json({ results: 'will not be cached' })
})

app.get('/api/found', cacheSuccesses, (req, res) => {
  res.json({ results: 'will be cached' })
})

Prevent cache-control header "max-age" from automatically being set to expiration age

let cache = apicache.options({
  headers: {
    'cache-control': 'no-cache',
  },
}).middleware

let cache5min = cache('5 minute') // continue to use normally

API

apicache.options([globalOptions]) - getter/setter for global options. If used as a setter, this function is chainable, allowing you to do things such as... say... return the middleware.
apicache.middleware([duration], [toggleMiddleware], [localOptions]) - the actual middleware that will be used in your routes. duration is in the following format "[length][unit]", as in "10 minutes" or "1 day". A second param is a middleware toggle function, accepting request and response params, and must return truthy to enable cache for the request. Third param is the options that will override global ones and affect this middleware only.
middleware.options([localOptions]) - getter/setter for middleware-specific options that will override global ones.
apicache.getPerformance() - returns current cache performance (cache hit rate)
apicache.getIndex() - returns current cache index [of keys]
apicache.clear([target]) - clears cache target (key or group), or entire cache if no value passed, returns new index.
apicache.newInstance([options]) - used to create a new ApiCache instance (by default, simply requiring this library shares a common instance)
apicache.clone() - used to create a new ApiCache instance with the same options as the current one

Available Options (first value is default)

{
  debug:            false|true,     // if true, enables console output
  defaultDuration:  '1 hour',       // should be either a number (in ms) or a string, defaults to 1 hour
  enabled:          true|false,     // if false, turns off caching globally (useful on dev)
  redisClient:      client,         // if provided, uses the [node-redis](https://github.com/NodeRedis/node_redis) client instead of [memory-cache](https://github.com/ptarjan/node-cache)
  appendKey:        fn(req, res),   // appendKey takes the req/res objects and returns a custom value to extend the cache key
  headerBlacklist:  [],             // list of headers that should never be cached
  statusCodes: {
    exclude:        [],             // list status codes to specifically exclude (e.g. [404, 403] cache all responses unless they had a 404 or 403 status)
    include:        [],             // list status codes to require (e.g. [200] caches ONLY responses with a success/200 code)
  },
  trackPerformance: false,          // enable/disable performance tracking... WARNING: super cool feature, but may cause memory overhead issues
  headers: {
    // 'cache-control':  'no-cache' // example of header overwrite
  },
  respectCacheControl: false|true   // If true, 'Cache-Control: no-cache' in the request header will bypass the cache.
}

*Optional: Typescript Types (courtesy of @danielsogl)

$ npm install -D @types/apicache

Custom Cache Keys

Sometimes you need custom keys (e.g. save routes per-session, or per method). We've made it easy!

Note: All req/res attributes used in the generation of the key must have been set previously (upstream). The entire route logic block is skipped on future cache hits so it can't rely on those params.

apicache.options({
  appendKey: (req, res) => req.method + res.session.id,
})

Cache Key Groups

Oftentimes it benefits us to group cache entries, for example, by collection (in an API). This would enable us to clear all cached "post" requests if we updated something in the "post" collection for instance. Adding a simple req.apicacheGroup = [somevalue]; to your route enables this. See example below:

var apicache = require('apicache')
var cache = apicache.middleware

// GET collection/id
app.get('/api/:collection/:id?', cache('1 hour'), function(req, res, next) {
  req.apicacheGroup = req.params.collection
  // do some work
  res.send({ foo: 'bar' })
})

// POST collection/id
app.post('/api/:collection/:id?', function(req, res, next) {
  // update model
  apicache.clear(req.params.collection)
  res.send('added a new item, so the cache has been cleared')
})

Additionally, you could add manual cache control to the previous project with routes such as these:

// GET apicache index (for the curious)
app.get('/api/cache/index', function(req, res, next) {
  res.send(apicache.getIndex())
})

// GET apicache index (for the curious)
app.get('/api/cache/clear/:key?', function(req, res, next) {
  res.send(200, apicache.clear(req.params.key || req.query.key))
})

Debugging/Console Out

Using Node environment variables (plays nicely with the hugely popular debug module)

$ export DEBUG=apicache
$ export DEBUG=apicache,othermoduleThatDebugModuleWillPickUp,etc

By setting internal option

import apicache from 'apicache'

apicache.options({ debug: true })

Client-Side Bypass

When sharing GET routes between admin and public sites, you'll likely want the routes to be cached from your public client, but NOT cached when from the admin client. This is achieved by sending a "x-apicache-bypass": true header along with the requst from the admin. The presence of this header flag will bypass the cache, ensuring you aren't looking at stale data.

Contributors

Special thanks to all those that use this library and report issues, but especially to the following active users that have helped add to the core functionality!

@Chocobozzz - the savior of getting this to pass all the Node 14/15 tests again... thanks for everyone's patience!!!
@killdash9 - restify support, performance/stats system, and too much else at this point to list
@svozza - added restify tests, test suite refactor, and fixed header issue with restify. Node v7 + Restify v5 conflict resolution, etag/if-none-match support, etcetc, etc. Triple thanks!!!
@andredigenova - Added header blacklist as options, correction to caching checks
@peteboere - Node v7 headers update
@rutgernation - JSONP support
@enricsangra - added x-apicache-force-fetch header
@tskillian - custom appendKey path support
@agolden - Content-Encoding preservation (for gzip, etc)
@davidyang - express 4+ compatibility
@nmors - redis support
@maytis, @ashwinnaidu - redis expiration
@ubergesundheit - Corrected buffer accumulation using res.write with Buffers
@danielsogl - Keeping dev deps up to date, Typescript Types
@vectart - Added middleware local options support
@davebaol - Added string support to defaultDuration option (previously just numeric ms)
@Rauttis - Added ioredis support
@fernandolguevara - Added opt-out for performance tracking, great emergency fix, thank you!!

Bugfixes, tweaks, documentation, etc.

@Amhri, @Webcascade, @conmarap, @cjfurelid, @scambier, @lukechilds, @Red-Lv, @gesposito, @viebel, @RowanMeara, @GoingFast, @luin, @keithws, @daveross, @apascal, @guybrush

Changelog

v1.6.0 - added respectCacheControl option flag to force honoring no-cache (thanks @NaridaL!)
v1.5.4 - up to Node v15 support, HUGE thanks to @Chocobozzz and all the folks on the PR thread! <3
v1.5.3 - multiple fixes: Redis should be connected before using (thanks @guybrush)
v1.5.2 - multiple fixes: Buffer deprecation and _headers deprecation, { trackPerformance: false } by default per discussion (sorry semver...)
v1.5.1 - adds { trackPerformance } option to enable/disable performance tracking (thanks @fernandolguevara)
v1.5.0 - exposes apicache.getPerformance() for per-route cache metrics (@killdash9 continues to deliver)
v1.4.0 - cache-control header now auto-decrements in cached responses (thanks again, @killdash9)
v1.3.0 - [securityfix] apicache headers no longer embedded in cached responses when NODE_ENV === 'production' (thanks for feedback @satya-jugran, @smddzcy, @adamelliotfields). Updated deps, now requiring Node v6.00+.
v1.2.6 - middlewareToggle() now prevents response block on cache hit + falsy toggle (thanks @apascal)
v1.2.5 - uses native Node setHeader() rather than express.js header() (thanks @keithws and @daveross)
v1.2.4 - force content type to Buffer, using old and new Buffer creation syntax
v1.2.3 - add etag to if-none-match 304 support (thanks for the test/issue @svozza)
v1.2.2 - bugfix: ioredis.expire params (thanks @GoingFast and @luin)
v1.2.1 - Updated deps
v1.2.0 - Supports ioredis (thanks @Rauttis)
v1.1.1 - bugfixes in expiration timeout clearing and content header preservation under compression (thanks @RowanMeara and @samimakicc).
v1.1.0 - added the much-requested feature of a custom appendKey function (previously only took a path to a single request attribute). Now takes (request, response) objects and returns some value to be appended to the cache key.
v1.0.0 - stamping v0.11.2 into official production version, will now begin developing on branch v2.x (redesign)
v0.11.2 - dev-deps update, courtesy of @danielsogl
v0.11.1 - correction to status code caching, and max-age headers are no longer sent when not cached. middlewareToggle now works as intended with example of statusCode checking (checks during shouldCacheResponse cycle)
v0.11.0 - Added string support to defaultDuration option, previously just numeric ms - thanks @davebaol
v0.10.0 - added ability to blacklist headers (prevents caching) via options.headersBlacklist (thanks @andredigenova)
v0.9.1 - added eslint in prep for v1.x branch, minor ES6 to ES5 in master branch tests
v0.9.0 - corrected Node v7.7 & v8 conflicts with restify (huge thanks to @svozza for chasing this down and fixing upstream in restify itself). Added coveralls. Added middleware.localOptions support (thanks @vectart). Added ability to overwrite/embed headers (e.g. "cache-control": "no-cache") through options.
v0.8.8 - corrected to use node v7+ headers (thanks @peteboere)
v0.8.6, v0.8.7 - README update
v0.8.5 - dev dependencies update (thanks @danielsogl)
v0.8.4 - corrected buffer accumulation, with test support (thanks @ubergesundheit)
v0.8.3 - added tests for x-apicache-bypass and x-apicache-force-fetch (legacy) and fixed a bug in the latter (thanks @Red-Lv)
v0.8.2 - test suite and mock API refactor (thanks @svozza)
v0.8.1 - fixed restify support and added appropriate tests (thanks @svozza)
v0.8.0 - modifies response accumulation (thanks @killdash9) to support res.write + res.end accumulation, allowing integration with restify. Adds gzip support (Node v4.3.2+ now required) and tests.
v0.7.0 - internally sets cache-control/max-age headers of response object
v0.6.0 - removed final dependency (debug) and updated README
v0.5.0 - updated internals to use res.end instead of res.send/res.json/res.jsonp, allowing for any response type, adds redis tests
v0.4.0 - dropped lodash and memory-cache external dependencies, and bumped node version requirements to 4.0.0+ to allow Object.assign native support

Choosing the Right Caching Strategy for Node.js Applications

Npm Package Weekly Downloads Trend

Github Stars Ranking

Stat Detail

Choosing the Right Caching Strategy for Node.js Applications

🏗️ Core Architecture: What Each Package Actually Does

⏱️ TTL and Expiration Handling

🔄 Eviction Strategies: LRU vs TTL vs Manual

🌐 HTTP vs Data Caching: Different Use Cases

⚠️ Maintenance Status and Production Readiness

📊 Feature Comparison Table

🎯 Real-World Selection Guide

Scenario 1: Caching Database Query Results

Scenario 2: Caching External API Responses

Scenario 3: Express API Response Caching

Scenario 4: Multi-Environment Caching Strategy

Scenario 5: High-Performance In-Memory Cache

💡 Final Recommendations

How to Choose: apicache vs cache-manager vs cacheable-request vs lru-cache vs memory-cache vs node-cache

Popular Comparisons

Similar Npm Packages to apicache

Similar Npm Packages to cache-manager

Similar Npm Packages to cacheable-request

Similar Npm Packages to lru-cache

Similar Npm Packages to memory-cache

Similar Npm Packages to node-cache

README for apicache

A simple API response caching middleware for Express/Node using plain-english durations.

Supports Redis or built-in memory engine with auto-clearing.

Why?

Usage

Cache a route

Cache all routes

Use with Redis

Cache grouping and manual controls

Use with middleware toggle for fine control

Prevent cache-control header "max-age" from automatically being set to expiration age

API

Available Options (first value is default)

*Optional: Typescript Types (courtesy of @danielsogl)

Custom Cache Keys

Cache Key Groups

Debugging/Console Out

Using Node environment variables (plays nicely with the hugely popular debug module)

By setting internal option

Client-Side Bypass

Contributors

Bugfixes, tweaks, documentation, etc.

Changelog