cache-manager vs cacheable-request vs lru-cache vs memory-cache vs quick-lru
Caching Strategies and Libraries for Node.js Applications
Search packages..
cache-managercacheable-requestlru-cachememory-cachequick-lruSimilar Packages:

Caching Strategies and Libraries for Node.js Applications

These libraries provide solutions for storing and retrieving data efficiently to improve application performance. lru-cache and quick-lru offer in-memory storage with Least Recently Used eviction policies, suitable for simple key-value needs. cache-manager provides a wrapper that supports multiple storage backends (memory, Redis, etc.) and stacking. cacheable-request focuses specifically on caching HTTP requests based on standard HTTP headers. memory-cache is a simpler in-memory option but has fallen out of favor compared to more actively maintained alternatives.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
cache-manager01,97752.2 kB04 months agoMIT
cacheable-request01,97779.3 kB016 days agoMIT
lru-cache05,8782.73 MB24 days agoBlueOak-1.0.0
memory-cache01,598-329 years agoBSD-2-Clause
quick-lru076020.4 kB07 months agoMIT

Caching Strategies and Libraries for Node.js Applications

Caching is essential for building fast applications. It reduces database load, speeds up API responses, and improves user experience. The JavaScript ecosystem offers several tools for this, but they solve different problems. Some focus on HTTP requests, others on in-memory data structures, and some on abstracting storage backends. Let's compare cache-manager, cacheable-request, lru-cache, memory-cache, and quick-lru to help you pick the right tool.

🏗️ Architecture: Wrapper vs. Direct Implementation

The first decision is whether you need a direct data structure or an abstraction layer.

lru-cache provides a direct implementation of a Least Recently Used map. You interact with the data structure itself. It is fast and has no dependencies.

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

const cache = new LRUCache({ max: 500 });
cache.set('key', 'value');
const value = cache.get('key');

quick-lru is similar but focuses on minimalism. It also gives you a direct Map-like interface with LRU eviction.

// quick-lru: Direct usage
import QuickLRU from 'quick-lru';

const lru = new QuickLRU({ maxSize: 500 });
lru.set('key', 'value');
const value = lru.get('key');

cache-manager wraps storage engines. You don't talk to the memory directly; you talk to the manager, which talks to the store (memory, Redis, etc.).

// cache-manager: Abstraction layer
import cacheManager from 'cache-manager';

const cache = await cacheManager.caching({ store: 'memory', max: 500 });
await cache.set('key', 'value');
const value = await cache.get('key');

memory-cache is a direct in-memory store but uses a simpler, older API style compared to modern ES6 classes.

// memory-cache: Direct usage
import Cache from 'memory-cache';

const cache = new Cache();
cache.put('key', 'value');
const value = cache.get('key');

cacheable-request is different. It wraps HTTP requests, not just data. It caches the response of a network call.

// cacheable-request: HTTP wrapper
import CacheableRequest from 'cacheable-request';

const cacheableRequest = new CacheableRequest(request);
const emit = cacheableRequest.get('https://api.example.com/data');
emit.on('response', response => { /* handle response */ });

⏱️ Time-To-Live (TTL) Management

Most caches need to expire data. The way they handle this varies significantly.

lru-cache supports TTL per item or globally. It automatically removes stale items on access or via a background process in newer versions.

// lru-cache: TTL support
const cache = new LRUCache({ 
  max: 500, 
  ttl: 1000 * 60 * 5 // 5 minutes 
});
cache.set('key', 'value');

cache-manager handles TTL through its store configuration. When setting a value, you pass the time in seconds.

// cache-manager: TTL support
await cache.set('key', 'value', { ttl: 300 }); // 5 minutes

memory-cache allows you to pass a timeout in milliseconds when putting a value.

// memory-cache: TTL support
cache.put('key', 'value', 300 * 1000); // 5 minutes in ms

quick-lru does not support TTL natively. It only evicts based on size (maxSize). You would need to build time-based expiration yourself.

// quick-lru: No native TTL
// You must store timestamps manually
const lru = new QuickLRU({ maxSize: 500 });
lru.set('key', { value: 'data', timestamp: Date.now() });
// Custom logic needed to check timestamp on get()

cacheable-request relies on HTTP headers. It respects Cache-Control, Expires, and ETag from the server response.

// cacheable-request: HTTP Header TTL
// Automatically parses 'Cache-Control: max-age=300' from server
const emit = cacheableRequest.get('https://api.example.com/data');

🧹 Eviction Policies: LRU vs. Simple Expiration

When the cache is full, what gets removed?

lru-cache strictly follows Least Recently Used. The item you haven't touched in the longest time goes first.

// lru-cache: Strict LRU
const cache = new LRUCache({ max: 2 });
cache.set('a', 1);
cache.set('b', 2);
cache.set('c', 3); // 'a' is evicted
console.log(cache.has('a')); // false

quick-lru also uses LRU eviction but is optimized for speed and simplicity.

// quick-lru: Strict LRU
const lru = new QuickLRU({ maxSize: 2 });
lru.set('a', 1);
lru.set('b', 2);
lru.set('c', 3); // 'a' is evicted
console.log(lru.has('a')); // false

memory-cache uses expiration primarily. While it has a max size, its main focus is time-based expiration rather than strict access-order eviction.

// memory-cache: Expiration focus
cache.put('a', 1, 1000);
cache.put('b', 2, 1000);
// Eviction happens based on checkInterval and timeouts

cache-manager depends on the underlying store. The memory store uses LRU, but a Redis store might use different strategies configured on the Redis side.

// cache-manager: Store dependent
// Memory store uses LRU, Redis uses Redis policies
const cache = await cacheManager.caching({ store: 'memory', max: 2 });

cacheable-request does not evict based on LRU in the traditional sense. It stores responses on disk or memory based on HTTP validity.

// cacheable-request: HTTP validity
// Stores responses until HTTP headers say they are stale

🛠️ Maintenance and Status

Choosing a library also means choosing a maintainer. Some of these packages are older and less active.

lru-cache is actively maintained and widely used in the Node.js core ecosystem. It receives regular updates for performance and security.

cache-manager is actively maintained. It is the go-to for multi-store caching in Node.js servers.

cacheable-request is maintained and commonly used with the got HTTP client. It is stable for HTTP caching needs.

quick-lru is stable and maintained by a well-known open-source developer. It is lightweight and reliable.

memory-cache shows signs of age. It has not seen significant updates in a long time. It is often flagged as a legacy option.

⚠️ Warning: memory-cache is not recommended for new projects. It lacks the modern features and active security patches of lru-cache.

🌐 Real-World Scenarios

Scenario 1: Caching API Responses in a Backend

You are building a Node.js API. You want to cache database query results in memory to reduce load.

  • ✅ Best choice: lru-cache
  • Why? You need strict memory limits and TTL to prevent memory leaks in a long-running process.
// lru-cache: Backend data caching
const queryCache = new LRUCache({ max: 1000, ttl: 60000 });
async function getUser(id) {
  if (queryCache.has(id)) return queryCache.get(id);
  const user = await db.query(id);
  queryCache.set(id, user);
  return user;
}

Scenario 2: Caching HTTP Requests in a Scraper

You are scraping websites. You want to avoid hitting the same URL twice within an hour.

  • ✅ Best choice: cacheable-request
  • Why? It handles HTTP semantics (ETags, 304 Not Modified) automatically.
// cacheable-request: HTTP scraping
const cacheableRequest = new CacheableRequest(request);
const emit = cacheableRequest.get('https://target.com/page');

Scenario 3: Multi-Layer Caching (Memory + Redis)

You have a high-traffic app. You want fast local memory cache backed by a shared Redis cache.

  • ✅ Best choice: cache-manager
  • Why? It supports stacking stores out of the box.
// cache-manager: Stacking stores
const multiCache = await cacheManager.multiCaching([memoryCache, redisCache]);
await multiCache.set('key', 'value');

Scenario 4: Lightweight Frontend Utility

You need a small cache in a browser extension or a small utility script without heavy dependencies.

  • ✅ Best choice: quick-lru
  • Why? It has zero dependencies and a tiny footprint.
// quick-lru: Frontend utility
const lru = new QuickLRU({ maxSize: 100 });
lru.set('config', settings);

📊 Summary Table

Featurelru-cachequick-lrucache-managermemory-cachecacheable-request
Primary UseIn-memory dataIn-memory dataMulti-store wrapperIn-memory dataHTTP requests
EvictionLRULRUStore-dependentExpiration/SizeHTTP Headers
TTL Support✅ Native❌ Manual✅ Native✅ Native✅ HTTP Headers
DependenciesNoneNoneFewNoneFew
StatusActiveActiveActiveLegacyActive

💡 Final Recommendation

For most Node.js applications needing in-memory caching, lru-cache is the standard choice. It balances features, performance, and maintenance.

If you need to cache HTTP calls specifically, cacheable-request saves you from reinventing the wheel for header parsing.

If you need to abstract over Redis and Memory together, cache-manager is the only one on this list that handles that architecture.

Avoid memory-cache in new work. Use quick-lru when you need something smaller and simpler than lru-cache without TTL needs.

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

  • cache-manager:

    Choose cache-manager if you need a unified interface for multiple caching backends like Redis or memory, or if you require stacking caches (e.g., memory + Redis). It is ideal for server-side applications where flexibility and abstraction over the storage layer are critical.

  • cacheable-request:

    Choose cacheable-request if your primary goal is to cache HTTP GET requests automatically based on standard HTTP headers. It integrates well with the got HTTP client and is best for reducing network overhead in data-fetching layers.

  • lru-cache:

    Choose lru-cache if you need a robust, feature-rich in-memory cache with strict LRU eviction, TTL support, and size limits. It is the industry standard for pure JavaScript in-memory caching in Node.js environments.

  • memory-cache:

    Avoid memory-cache for new projects as it is less actively maintained and lacks features found in modern alternatives. Only consider it for legacy systems where it is already deeply integrated and changing it poses too much risk.

  • quick-lru:

    Choose quick-lru if you need a minimal, dependency-free LRU cache with a simple API and no external dependencies. It is perfect for lightweight frontend or backend tasks where you just need basic max-size eviction without extra features.

Similar Npm Packages to cache-manager

cache-manager is a versatile caching library for Node.js applications. It provides a simple and consistent API for managing caching across different storage engines, such as memory, Redis, and more. With cache-manager, developers can easily implement caching strategies to improve application performance and reduce the load on backend services. While cache-manager is a robust solution for caching, there are several alternatives available that cater to different use cases. Here are a few notable options:

  • apicache is a lightweight caching middleware for Express.js applications. It allows developers to cache API responses easily, improving response times and reducing server load. apicache is particularly useful for applications that require quick access to frequently requested data, as it can significantly enhance performance with minimal configuration. If you're building an API with Express and want a straightforward way to implement caching, apicache is an excellent choice.

  • cacheable-request is a caching wrapper for HTTP requests. It allows developers to cache responses from HTTP requests, making it a great option for applications that rely heavily on external APIs. By using cacheable-request, developers can reduce the number of requests made to external services, thereby improving performance and reducing costs. This library is particularly useful for applications that need to fetch data from APIs frequently and can benefit from caching those responses.

  • lru-cache is a simple and efficient implementation of a Least Recently Used (LRU) cache. It is designed to store a limited number of items in memory, automatically evicting the least recently used items when the cache reaches its size limit. lru-cache is ideal for scenarios where memory usage is a concern, and you want to ensure that your application only retains the most relevant data in cache. Its straightforward API makes it easy to integrate into any Node.js application.

  • memory-cache is a simple in-memory caching library for Node.js. It provides a straightforward API for storing and retrieving data in memory, making it suitable for applications that require quick access to cached data without the overhead of more complex caching solutions. If you need a lightweight and easy-to-use caching solution for your Node.js application, memory-cache is a solid option.

  • node-cache is another in-memory caching library for Node.js that offers a simple key-value store. It supports features like time-to-live (TTL) for cache entries, allowing developers to control how long data remains in the cache. node-cache is useful for applications that require a straightforward caching mechanism without the complexity of external storage solutions.

To explore how these caching libraries compare, check out the comparison: Comparing apicache vs cache-manager vs cacheable-request vs lru-cache vs memory-cache vs node-cache.

Similar Npm Packages to cacheable-request

cacheable-request is a Node.js library that enhances HTTP requests by adding caching capabilities. It allows developers to cache the responses of HTTP requests, reducing the need for repeated network calls and improving application performance. This library is particularly useful for applications that frequently request the same resources, as it can significantly reduce latency and server load. While cacheable-request provides a solid foundation for caching HTTP requests, there are several alternatives in the Node.js ecosystem that offer similar functionalities. Here are a few notable ones:

  • axios-cache-adapter is an adapter for Axios that adds caching functionality to HTTP requests. It allows developers to cache responses and configure cache settings easily. If you are already using Axios for making HTTP requests, integrating axios-cache-adapter can be a seamless way to add caching without changing your existing code structure. This library is particularly useful for applications that rely heavily on Axios and require efficient caching mechanisms.

  • cache-manager is a multi-store caching library for Node.js that provides a unified API for various caching stores, including memory, Redis, and more. It allows developers to manage cache easily and supports features like time-to-live (TTL) and cache expiration. If you need a more comprehensive caching solution that can work with different storage backends, cache-manager is a versatile choice.

  • lru-cache is a simple and efficient implementation of a Least Recently Used (LRU) cache. It is designed for in-memory caching, making it suitable for scenarios where you need fast access to cached data. If your application requires a straightforward in-memory caching solution without the overhead of network requests, lru-cache is an excellent option.

  • memory-cache is another lightweight in-memory caching library for Node.js. It provides a simple API for storing and retrieving cached data in memory. If you are looking for a minimalistic caching solution that is easy to implement and use, memory-cache is a good choice.

  • node-cache is a simple caching module for Node.js that allows you to store key-value pairs in memory. It supports features like TTL and automatic cache expiration. If you need a straightforward caching mechanism for your Node.js application without complex configurations, node-cache is a suitable option.

To see how cacheable-request compares with these alternatives, check out the comparison: Comparing axios-cache-adapter vs cache-manager vs cacheable-request vs lru-cache vs memory-cache vs node-cache.

Similar Npm Packages to lru-cache

lru-cache is a popular caching library for Node.js and JavaScript applications that implements a Least Recently Used (LRU) caching strategy. This means that it automatically removes the least recently accessed items from the cache when it reaches its maximum size, ensuring that the most frequently used data remains available. This makes lru-cache an excellent choice for optimizing performance in applications that require quick access to frequently used data.

While lru-cache is a robust solution for caching, there are several alternatives available that also provide caching capabilities. Here are a few notable options:

  • memory-cache is a simple and lightweight caching library for Node.js applications. It allows you to store key-value pairs in memory with an optional expiration time. Unlike lru-cache, memory-cache does not implement an LRU eviction policy, making it a straightforward choice for applications that require basic caching without the complexity of eviction strategies. It's ideal for small projects or scenarios where caching needs are minimal.

  • node-cache is another caching library designed specifically for Node.js applications. It provides a simple API for storing and retrieving data in memory, along with features like time-to-live (TTL) for cache entries. While it does not implement an LRU eviction policy by default, it offers a more comprehensive set of features compared to memory-cache, making it suitable for applications that require more control over caching behavior.

  • quick-lru is a lightweight and fast LRU cache implementation for JavaScript. It is designed to be simple and efficient, providing a minimal API for managing cached items. quick-lru is an excellent choice for developers looking for a straightforward LRU caching solution without the overhead of additional features. Its performance and simplicity make it a great alternative for applications that need efficient caching without unnecessary complexity.

To see how lru-cache compares with memory-cache, node-cache, and quick-lru, check out the comparison: Comparing lru-cache vs memory-cache vs node-cache vs quick-lru.

Similar Npm Packages to memory-cache

memory-cache is a simple and efficient caching library for Node.js applications. It allows developers to store key-value pairs in memory, providing a fast way to access frequently used data without the need for repeated calculations or database queries. While memory-cache is a great choice for in-memory caching, there are several alternatives that offer similar functionality. Here are a few noteworthy options:

  • lru-cache is a popular caching library that implements a Least Recently Used (LRU) cache algorithm. This means that it automatically removes the least recently accessed items when the cache reaches its limit, making it ideal for applications where memory usage needs to be optimized. lru-cache is particularly useful for scenarios where you want to maintain a limited amount of cached data while ensuring that the most frequently accessed items remain available. Its flexibility and efficiency make it a preferred choice for many developers looking for a robust caching solution.
  • node-cache is another caching library designed specifically for Node.js applications. It provides a simple API for storing and retrieving cached data, along with features like time-to-live (TTL) for cache entries, allowing developers to set expiration times for cached items. node-cache is well-suited for applications that require a straightforward caching mechanism with the ability to manage cache lifetimes effectively. Its ease of use and built-in expiration features make it a solid choice for many caching scenarios.
  • quick-lru is a lightweight and efficient LRU caching library that focuses on performance. It is designed to be simple and fast, making it an excellent choice for applications that require a minimalistic approach to caching. quick-lru allows developers to easily set limits on the cache size and provides a straightforward API for adding and retrieving cached items. If you are looking for a high-performance caching solution without unnecessary complexity, quick-lru is worth considering.

To see how memory-cache compares with lru-cache, node-cache, and quick-lru, check out the comparison: Comparing lru-cache vs memory-cache vs node-cache vs quick-lru.

Similar Npm Packages to quick-lru

quick-lru is a lightweight and efficient caching library for Node.js applications. It implements a Least Recently Used (LRU) cache, which automatically removes the least recently accessed items when the cache reaches its limit. This makes it an ideal choice for applications that require fast access to frequently used data while efficiently managing memory usage. While quick-lru is a solid option for caching, there are several alternatives available in the ecosystem. Here are a few notable ones:

  • cache-manager is a versatile caching library that provides a simple and consistent API for managing various caching stores. It supports multiple backends, including memory, Redis, and more, allowing developers to choose the most suitable storage mechanism for their applications. If you need a more comprehensive caching solution that can work with different storage options and provides additional features like cache expiration and serialization, cache-manager is an excellent choice.
  • cacheable-request is a caching library specifically designed for HTTP requests. It wraps around the native http and https modules, allowing developers to easily cache responses from HTTP requests. This library is particularly useful for applications that make frequent API calls and want to reduce the number of requests sent to the server. If your primary focus is on caching HTTP responses, cacheable-request is a great option.
  • lru-cache is another popular LRU caching library that provides a simple and efficient way to manage in-memory caches. It allows developers to set a maximum size for the cache and automatically evicts the least recently used items when the limit is reached. With its straightforward API and good performance, lru-cache is a solid choice for applications that require a reliable in-memory caching solution.
  • memory-cache is a simple in-memory caching library that provides basic caching functionality. It allows developers to store key-value pairs in memory and set expiration times for cached items. While it may not have all the advanced features of other libraries, memory-cache is easy to use and can be a good fit for smaller applications or projects that require basic caching capabilities.

To see how quick-lru compares with cache-manager, cacheable-request, lru-cache, and memory-cache, check out the comparison: Comparing cache-manager vs cacheable-request vs lru-cache vs memory-cache vs quick-lru.

README for cache-manager

Cacheable

cache-manager

codecov tests npm npm license

Simple and fast NodeJS caching module.

A cache module for NodeJS that allows easy wrapping of functions in cache, tiered caches, and a consistent interface.

  • Made with Typescript and compatible with ESModules.
  • Easy way to wrap any function in cache, supports a mechanism to refresh expiring cache keys in background.
  • Tiered caches -- data gets stored in each cache and fetched from the highest priority cache(s) first.
  • nonBlocking option that optimizes how the system handles multiple stores.
  • Use with any Keyv compatible storage adapter.
  • 100% test coverage via vitest.

We moved to using Keyv which are more actively maintained and have a larger community.

A special thanks to Tim Phan who took cache-manager v5 and ported it to Keyv which is the foundation of v6. 🎉 Another special thanks to Doug Ayers who wrote promise-coalesce which was used in v5 and now embedded in v6.

Migration from v6 to v7

v7 has only one breaking change which is changing the return type from null to undefined when there is no data to return. This is to align with the Keyv API and to make it more consistent with the rest of the methods. Below is an example of how to migrate from v6 to v7:

import { createCache } from 'cache-manager';

const cache = createCache();
const result = await cache.get('key');
// result will be undefined if the key is not found or expired
console.log(result); // undefined

Migration from v5 to v6

v6 is a major update and has breaking changes primarily around the storage adapters. We have moved to using Keyv which are more actively maintained and have a larger community. Below are the changes you need to make to migrate from v5 to v6. In v5 the memoryStore was used to create a memory store, in v6 you can use any storage adapter that Keyv supports. Below is an example of how to migrate from v5 to v6:

import { createCache, memoryStore } from 'cache-manager';

// Create memory cache synchronously
const memoryCache = createCache(memoryStore({
  max: 100,
  ttl: 10 * 1000 /*milliseconds*/,
}));

In v6 you can use any storage adapter that Keyv supports. Below is an example of using the in memory store with Keyv:

import { createCache } from 'cache-manager';

const cache = createCache();

If you would like to do multiple stores you can do the following:

import { createCache } from 'cache-manager';
import { createKeyv } from 'cacheable';
import { createKeyv as createKeyvRedis } from '@keyv/redis';

const memoryStore = createKeyv();
const redisStore = createKeyvRedis('redis://user:pass@localhost:6379');

const cache = createCache({
  stores: [memoryStore, redisStore],
});

When doing in memory caching and getting errors on symbol or if the object is coming back wrong like on Uint8Array you will want to set the serialization and deserialization options in Keyv to undefined as it will try to do json serialization.

import { createCache } from "cache-manager";
import { Keyv } from "keyv";

const keyv = new Keyv();
keyv.serialize = undefined;
keyv.deserialize = undefined;

const memoryCache = createCache({
	stores: [keyv],
});

The other option is to set the serialization to something that is not JSON.stringify. You can read more about it here: https://keyv.org/docs/keyv/#custom-serializers

If you would like a more robust in memory storage adapter you can use CacheableMemory from Cacheable. Below is an example of how to migrate from v5 to v6 using CacheableMemory:

import { createCache } from 'cache-manager';
import { createKeyv } from 'cacheable';

const cache = createCache({
  stores: [createKeyv({ ttl: 60000, lruSize: 5000 })],
});

To learn more about CacheableMemory please visit: http://cacheable.org/docs/cacheable/#cacheablememory---in-memory-cache

If you are still wanting to use the legacy storage adapters you can use the KeyvAdapter to wrap the storage adapter. Below is an example of how to migrate from v5 to v6 using cache-manager-redis-yet by going to Using Legacy Storage Adapters.

If you are looking for older documentation you can find it here:

Table of Contents

Installation

npm install cache-manager

By default, everything is stored in memory; you can optionally also install a storage adapter; choose one from any of the storage adapters supported by Keyv:

npm install @keyv/redis
npm install @keyv/memcache
npm install @keyv/mongo
npm install @keyv/sqlite
npm install @keyv/postgres
npm install @keyv/mysql
npm install @keyv/etcd

In addition Keyv supports other storage adapters such as lru-cache and CacheableMemory from Cacheable (more examples below). Please read Keyv document for more information.

Quick start

import { Keyv } from 'keyv';
import { createCache } from 'cache-manager';

// Memory store by default
const cache = createCache()

// Single store which is in memory
const cache = createCache({
  stores: [new Keyv()],
})

Here is an example of doing layer 1 and layer 2 caching with the in-memory being CacheableMemory from Cacheable and the second layer being @keyv/redis:

import { Keyv } from 'keyv';
import KeyvRedis from '@keyv/redis';
import { CacheableMemory } from 'cacheable';
import { createCache } from 'cache-manager';

// Multiple stores
const cache = createCache({
  stores: [
    //  High performance in-memory cache with LRU and TTL
    new Keyv({
      store: new CacheableMemory({ ttl: 60000, lruSize: 5000 }),
    }),

    //  Redis Store
    new Keyv({
      store: new KeyvRedis('redis://user:pass@localhost:6379'),
    }),
  ],
})

Once it is created, you can use the cache object to set, get, delete, and wrap functions in cache.


// With default ttl and refreshThreshold
const cache = createCache({
  ttl: 10000,
  refreshThreshold: 3000,
})

await cache.set('foo', 'bar')
// => bar

await cache.get('foo')
// => bar

await cache.del('foo')
// => true

await cache.get('foo')
// => null

await cache.wrap('key', () => 'value')
// => value

Using CacheableMemory or lru-cache as storage adapter

Because we are using Keyv, you can use any storage adapter that Keyv supports such as lru-cache or CacheableMemory from Cacheable. Below is an example of using CacheableMemory:

In this example we are using CacheableMemory from Cacheable which is a fast in-memory cache that supports LRU and and TTL expiration.

import { createCache } from 'cache-manager';
import { Keyv } from 'keyv';
import { KeyvCacheableMemory } from 'cacheable';

const store = new KeyvCacheableMemory({ ttl: 60000, lruSize: 5000 });
const keyv = new Keyv({ store });
const cache = createCache({ stores: [keyv] });

Here is an example using lru-cache:

import { createCache } from 'cache-manager';
import { Keyv } from 'keyv';
import { LRU } from 'lru-cache';

const keyv = new Keyv({ store: new LRU({ max: 5000, maxAge: 60000 }) });
const cache = createCache({ stores: [keyv] });

Options

  • stores?: Keyv[]

    List of Keyv instance. Please refer to the Keyv document for more information.

  • ttl?: number - Default time to live in milliseconds.

    The time to live in milliseconds. This is the maximum amount of time that an item can be in the cache before it is removed.

  • refreshThreshold?: number | (value:T) => number - Default refreshThreshold in milliseconds. You can also provide a function that will return the refreshThreshold based on the value.

    If the remaining TTL is less than refreshThreshold, the system will update the value asynchronously in background.

  • refreshAllStores?: boolean - Default false

    If set to true, the system will update the value of all stores when the refreshThreshold is met. Otherwise, it will only update from the top to the store that triggered the refresh.

  • nonBlocking?: boolean - Default false

    If set to true, the system will not block when multiple stores are used. Here is how it affects the type of functions:

    • set and mset - will not wait for all stores to finish.
    • get and mget - will return the first (fastest) value found.
    • del and mdel - will not wait for all stores to finish.
    • clear - will not wait for all stores to finish.
    • wrap - will do the same as get and set (return the first value found and not wait for all stores to finish).

  • cacheId?: string - Defaults to random string

    Unique identifier for the cache instance. This is primarily used to not have conflicts when using wrap with multiple cache instances.

Methods

set

set(key, value, [ttl]): Promise<value>

Sets a key value pair. It is possible to define a ttl (in milliseconds). An error will be throw on any failed

await cache.set('key-1', 'value 1')

// expires after 5 seconds
await cache.set('key 2', 'value 2', 5000)

See unit tests in test/set.test.ts for more information.

mset

mset(keys: [ { key, value, ttl } ]): Promise<true>

Sets multiple key value pairs. It is possible to define a ttl (in milliseconds). An error will be throw on any failed

await cache.mset([
  { key: 'key-1', value: 'value 1' },
  { key: 'key-2', value: 'value 2', ttl: 5000 },
]);

get

get(key): Promise<value>

Gets a saved value from the cache. Returns a null if not found or expired. If the value was found it returns the value.

await cache.set('key', 'value')

await cache.get('key')
// => value

await cache.get('foo')
// => null

See unit tests in test/get.test.ts for more information.

mget

mget(keys: [key]): Promise<value[]>

Gets multiple saved values from the cache. Returns a null if not found or expired. If the value was found it returns the value.

await cache.mset([
  { key: 'key-1', value: 'value 1' },
  { key: 'key-2', value: 'value 2' },
]);

await cache.mget(['key-1', 'key-2', 'key-3'])
// => ['value 1', 'value 2', null]

ttl

ttl(key): Promise<number | null>

Gets the expiration time of a key in milliseconds. Returns a null if not found or expired.

await cache.set('key', 'value', 1000); // expires after 1 second

await cache.ttl('key'); // => the expiration time in milliseconds

await cache.get('foo'); // => null

See unit tests in test/ttl.test.ts for more information.

del

del(key): Promise<true>

Delete a key, an error will be throw on any failed.

await cache.set('key', 'value')

await cache.get('key')
// => value

await cache.del('key')

await cache.get('key')
// => null

See unit tests in test/del.test.ts for more information.

mdel

mdel(keys: [key]): Promise<true>

Delete multiple keys, an error will be throw on any failed.

await cache.mset([
  { key: 'key-1', value: 'value 1' },
  { key: 'key-2', value: 'value 2' },
]);

await cache.mdel(['key-1', 'key-2'])

clear

clear(): Promise<true>

Flush all data, an error will be throw on any failed.

await cache.set('key-1', 'value 1')
await cache.set('key-2', 'value 2')

await cache.get('key-1')
// => value 1
await cache.get('key-2')
// => value 2

await cache.clear()

await cache.get('key-1')
// => null
await cache.get('key-2')
// => null

See unit tests in test/clear.test.ts for more information.

wrap

wrap(key, fn: async () => value, [ttl], [refreshThreshold]): Promise<value>

Alternatively, with optional parameters as options object supporting a raw parameter:

wrap(key, fn: async () => value, { ttl?: number, refreshThreshold?: number, raw?: true }): Promise<value>

Wraps a function in cache. The first time the function is run, its results are stored in cache so subsequent calls retrieve from cache instead of calling the function.

If refreshThreshold is set and the remaining TTL is less than refreshThreshold, the system will update the value asynchronously. In the meantime, the system will return the old value until expiration. You can also provide a function that will return the refreshThreshold based on the value (value:T) => number.

If the object format for the optional parameters is used, an additional raw parameter can be applied, changing the function return type to raw data including expiration timestamp as { value: [data], expires: [timestamp] }.

await cache.wrap('key', () => 1, 5000, 3000)
// call function then save the result to cache
// =>  1

await cache.wrap('key', () => 2, 5000, 3000)
// return data from cache, function will not be called again
// => 1

await cache.wrap('key', () => 2, { ttl: 5000, refreshThreshold: 3000, raw: true })
// returns raw data including expiration timestamp
// => { value: 1, expires: [timestamp] }

// wait 3 seconds
await sleep(3000)

await cache.wrap('key', () => 2, 5000, 3000)
// return data from cache, call function in background and save the result to cache
// =>  1

await cache.wrap('key', () => 3, 5000, 3000)
// return data from cache, function will not be called
// =>  2

await cache.wrap('key', () => 4, 5000, () => 3000);
// return data from cache, function will not be called
// =>  4

await cache.wrap('error', () => {
  throw new Error('failed')
})
// => error

NOTES:

  • The store that will be checked for refresh is the one where the key will be found first (highest priority).
  • If the threshold is low and the worker function is slow, the key may expire and you may encounter a racing condition with updating values.
  • If no ttl is set for the key, the refresh mechanism will not be triggered.

See unit tests in test/wrap.test.ts for more information.

disconnect

disconnect(): Promise<void>

Will disconnect from the relevant store(s). It is highly recommended to use this when using a Keyv storage adapter that requires a disconnect. For each storage adapter, the use case for when to use disconnect is different. An example is that @keyv/redis should be used only when you are done with the cache.

await cache.disconnect();

See unit tests in test/disconnect.test.ts for more information.

Properties

cacheId

cacheId(): string

Returns cache instance id. This is primarily used to not have conflicts when using wrap with multiple cache instances.

stores

stores(): Keyv[]

Returns the list of Keyv instances. This can be used to get the list of stores and then use the Keyv API to interact with the store directly.

const cache = createCache({cacheId: 'my-cache-id'});
cache.cacheId(); // => 'my-cache-id'

See unit tests in test/cache-id.test.ts for more information.

Events

set

Fired when a key has been added or changed.

cache.on('set', ({ key, value, error }) => {
	// ... do something ...
})

del

Fired when a key has been removed manually.

cache.on('del', ({ key, error }) => {
	// ... do something ...
})

clear

Fired when the cache has been flushed.

cache.on('clear', (error) => {
  if (error) {
    // ... do something ...
  }
})

refresh

Fired when the cache has been refreshed in the background.

cache.on('refresh', ({ key, value, error }) => {
  if (error) {
    // ... do something ...
  }
})

See unit tests in test/events.test.ts for more information.

Doing Iteration on Stores

You can use the stores method to get the list of stores and then use the Keyv API to interact with the store directly. Below is an example of iterating over all stores and getting all keys:

import Keyv from 'keyv';
import { createKeyv } from '@keyv/redis';
import { createCache } from 'cache-manager';

const keyv = new Keyv();
const keyvRedis = createKeyv('redis://user:pass@localhost:6379');

const cache = createCache({
  stores: [keyv, keyvRedis],
});

// add some data
await cache.set('key-1', 'value 1');
await cache.set('key-2', 'value 2');

// get the store you want to iterate over. In this example we are using the second store (redis)
const store = cache.stores[1];

if(store?.iterator) {
  for await (const [key, value] of store.iterator({})) {
    console.log(key, value);
  }
}

WARNING: Be careful when using iterator as it can cause major performance issues with the amount of data being retrieved. Also, Not all storage adapters support iterator so you may need to check the documentation for the storage adapter you are using.

Update on redis and ioredis Support

We will not be supporting cache-manager-ioredis-yet or cache-manager-redis-yet in the future as we have moved to using Keyv as the storage adapter @keyv/redis.

Using Legacy Storage Adapters

There are many storage adapters built for cache-manager and because of that we wanted to provide a way to use them with KeyvAdapter. Below is an example of using cache-manager-redis-yet:

import { createCache, KeyvAdapter } from 'cache-manager';
import { Keyv } from 'keyv';
import { redisStore } from 'cache-manager-redis-yet';

const adapter = new KeyvAdapter( await redisStore() );
const keyv = new Keyv({ store: adapter });
const cache = createCache({ stores: [keyv]});

This adapter will allow you to add in any storage adapter. If there are issues it needs to follow CacheManagerStore interface.

Contribute

If you would like to contribute to the project, please read how to contribute here CONTRIBUTING.md.

License

MIT © Jared Wray

npm-compare.com is an independent website designed to help developers choose the most suitable npm packages. We are not affiliated with npm, Inc, the official website for the npm registry. Note that npm is a registered trademark of npm, Inc. Please share your feedback via our GitHub repository. For more details, please refer to our Terms & Privacy.