node-cache vs memory-cache vs apicache vs lru-cache
Node.js Caching Libraries
Search packages..
node-cachememory-cacheapicachelru-cacheSimilar Packages:

Node.js Caching Libraries

Caching libraries in Node.js are used to temporarily store data in memory to improve application performance by reducing the need to repeatedly fetch data from slower storage systems, such as databases or external APIs. These libraries provide mechanisms to manage cached data, including expiration policies, eviction strategies, and memory management, allowing developers to optimize their applications for speed and efficiency.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
node-cache3,889,1302,375-776 years agoMIT
memory-cache695,9211,602-329 years agoBSD-2-Clause
apicache34,7831,249-634 years agoMIT
lru-cache05,851844 kB13 days agoBlueOak-1.0.0

Feature Comparison: node-cache vs memory-cache vs apicache vs lru-cache

Eviction Policy

  • node-cache:

    Node-Cache supports TTL (time-to-live) for cache entries, allowing developers to set expiration times for individual cache items. Once the TTL expires, the item is automatically removed from the cache, effectively managing memory usage.

  • memory-cache:

    Memory Cache does not have a built-in eviction policy. It simply stores key-value pairs in memory until the process is terminated or the cache is manually cleared. This makes it less suitable for applications with limited memory resources.

  • apicache:

    Apicache does not implement a traditional eviction policy since it is primarily focused on caching HTTP responses. It allows for manual cache invalidation and expiration settings but does not automatically remove items based on usage patterns.

  • lru-cache:

    LRU Cache employs a least-recently-used eviction policy, meaning that it will automatically remove the least recently accessed items from the cache when it reaches its size limit. This ensures that frequently accessed data remains available while older, less-used data is discarded.

Complexity

  • node-cache:

    Node-Cache offers a more complex API with various features such as TTL and cache management methods. While it provides more control, it may require a steeper learning curve compared to simpler options.

  • memory-cache:

    Memory Cache is the simplest of the options, providing a basic key-value store with no additional features. It is very easy to set up and use, making it ideal for quick caching needs without overhead.

  • apicache:

    Apicache is designed to be simple and easy to use, with minimal configuration required. It is particularly user-friendly for developers who want to implement caching for HTTP requests without delving into complex caching strategies.

  • lru-cache:

    LRU Cache is straightforward but requires some understanding of the least-recently-used strategy. It is easy to implement but may require additional logic to manage cache size and handle evictions effectively.

Use Case

  • node-cache:

    Node-Cache is ideal for applications that require a robust caching mechanism with expiration control. It is commonly used in scenarios where data needs to be cached for a specific duration, such as caching database query results.

  • memory-cache:

    Memory Cache is suitable for lightweight applications that require quick access to temporary data without the need for advanced features. It is often used for caching configuration settings or transient data.

  • apicache:

    Apicache is best suited for caching API responses in web applications, especially when dealing with high-frequency requests. It is ideal for scenarios where reducing response times for HTTP requests is critical.

  • lru-cache:

    LRU Cache is perfect for caching data that is frequently accessed but has a limited memory footprint. It is commonly used in applications where memory management is crucial, such as in-memory databases or caching user sessions.

Performance

  • node-cache:

    Node-Cache delivers good performance with its TTL feature, allowing for efficient memory usage and quick access to cached data. The ability to set expiration times helps maintain performance over time by preventing stale data.

  • memory-cache:

    Memory Cache offers fast access to cached data due to its in-memory nature. However, it lacks eviction policies, which can lead to memory exhaustion if not monitored, potentially impacting overall application performance.

  • apicache:

    Apicache can significantly improve performance for HTTP requests by reducing latency through caching. However, its performance is heavily dependent on the configuration of cache expiration and invalidation strategies.

  • lru-cache:

    LRU Cache provides excellent performance for read-heavy workloads, as it keeps frequently accessed data in memory. The eviction policy ensures that the cache remains efficient, but performance may degrade if the cache size is not managed properly.

Scalability

  • node-cache:

    Node-Cache is also an in-memory cache and does not support distributed caching out of the box. It is best used in single-instance applications, but can be combined with other solutions for larger applications.

  • memory-cache:

    Memory Cache is not designed for scalability, as it only stores data in the local memory of the Node.js process. It is suitable for small applications but may not perform well in larger, distributed environments.

  • apicache:

    Apicache is not inherently designed for distributed caching, which can limit its scalability in large applications. It is best suited for single-instance applications or when combined with other caching strategies for scalability.

  • lru-cache:

    LRU Cache is primarily an in-memory solution and may not scale well across multiple instances without additional mechanisms for synchronization. It is best used in scenarios where a single instance can handle the load.

How to Choose: node-cache vs memory-cache vs apicache vs lru-cache

  • node-cache:

    Use Node-Cache if you need a feature-rich caching solution that supports TTL (time-to-live) for cache entries. It provides a more comprehensive API for managing cached data and is ideal for applications that require more control over cache behavior.

  • memory-cache:

    Select Memory Cache for a straightforward in-memory caching solution that is easy to implement and use. It is best for applications that need a simple key-value store without complex features, making it suitable for lightweight caching needs.

  • apicache:

    Choose Apicache if you need a simple and effective caching solution specifically for HTTP requests. It is particularly useful for caching API responses and offers built-in support for cache expiration and invalidation, making it ideal for applications with frequent API calls.

  • lru-cache:

    Opt for LRU Cache when you require a cache with a least-recently-used eviction strategy. This package is well-suited for scenarios where memory usage is a concern, as it automatically removes the least recently accessed items when the cache reaches its limit, ensuring efficient memory management.

Similar Npm Packages to node-cache

node-cache is a simple and efficient caching module for Node.js applications. It provides an easy-to-use API for storing and retrieving cached data in memory, making it ideal for scenarios where quick access to frequently used data is required. With features like time-to-live (TTL) for cache entries and automatic cleanup of expired items, node-cache helps improve application performance by reducing the need for repeated data fetching or computation.

While node-cache is a solid choice for in-memory caching, there are several alternatives that offer different features and capabilities. Here are a few notable options:

  • lru-cache is a popular caching library that implements a Least Recently Used (LRU) caching strategy. This means that when the cache reaches its limit, it automatically removes the least recently accessed items to make space for new ones. lru-cache is particularly useful for applications that require efficient memory management and want to ensure that frequently accessed data remains available. Its flexibility and performance make it a great choice for caching scenarios where memory constraints are a concern.

  • memory-cache is another lightweight caching library for Node.js that provides a simple API for in-memory caching. It allows developers to store key-value pairs with optional expiration times. While memory-cache is straightforward and easy to use, it does not implement advanced caching strategies like LRU. It is best suited for smaller applications or scenarios where simplicity is preferred over complex caching mechanisms.

  • node-persist is a persistent storage library for Node.js that allows you to store data in a file-based cache. Unlike in-memory caching solutions, node-persist provides durability by saving data to the filesystem, making it suitable for applications that require data persistence across restarts. It offers a simple API for storing and retrieving data, along with features like automatic serialization and deserialization of JavaScript objects.

To compare these caching libraries, check out the following link: Comparing lru-cache vs memory-cache vs node-cache vs node-persist.

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 apicache

apicache is a caching middleware for Node.js applications, designed specifically for HTTP requests. It provides a simple way to cache API responses, reducing the load on servers and improving response times for clients. By caching responses, apicache helps to enhance the performance of applications, especially those that rely heavily on API calls. While apicache is a powerful tool for caching HTTP responses, there are several alternatives available in the Node.js ecosystem. Here are a few notable options:

  • lru-cache is a popular caching library that implements a Least Recently Used (LRU) caching strategy. It is designed for general-purpose caching and can be used in various scenarios, including caching API responses. With lru-cache, you can control the maximum size of the cache, ensuring that it automatically removes the least recently used entries when the limit is reached. This makes it a great choice for applications that require efficient memory management and fast access to cached data.

  • memory-cache is a simple in-memory caching library for Node.js. It provides a straightforward API for setting, getting, and deleting cache entries. Memory-cache is lightweight and easy to use, making it suitable for applications that need a quick and simple caching solution without the overhead of more complex libraries. However, since it stores data in memory, it is best suited for scenarios where the cached data does not need to persist across server restarts.

  • node-cache is another caching library for Node.js that provides a simple key-value store with an expiration feature. It allows you to set time-to-live (TTL) values for cache entries, automatically removing them after a specified duration. Node-cache is useful for caching data that is time-sensitive or for reducing the frequency of expensive operations, such as database queries or API calls.

To see how apicache compares with lru-cache, memory-cache, and node-cache, check out the comparison: Comparing apicache 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.

README for node-cache

Logo

Node.js CI Dependency status NPM package version NPM monthly downloads GitHub issues Coveralls Coverage

Simple and fast NodeJS internal caching.

A simple caching module that has set, get and delete methods and works a little bit like memcached. Keys can have a timeout (ttl) after which they expire and are deleted from the cache. All keys are stored in a single object so the practical limit is at around 1m keys.

BREAKING MAJOR RELEASE v5.x

The recent 5.x release:

  • dropped support for node versions before 8.x!
  • removed the callback-based api from all methods (you can re-enable them with the option enableLegacyCallbacks)

BREAKING MAJOR RELEASE v6.x UPCOMING

Although not breaking per definition, our typescript rewrite will change internal functions and their names. Please get in contact with us, if you are using some parts of node-cache's internal api so we can work something out!

Install

	npm install node-cache --save

Or just require the node_cache.js file to get the superclass

Examples:

Initialize (INIT):

const NodeCache = require( "node-cache" );
const myCache = new NodeCache();

Options

  • stdTTL: (default: 0) the standard ttl as number in seconds for every generated cache element. 0 = unlimited
  • checkperiod: (default: 600) The period in seconds, as a number, used for the automatic delete check interval. 0 = no periodic check.
  • useClones: (default: true) en/disable cloning of variables. If true you'll get a copy of the cached variable. If false you'll save and get just the reference.
    Note:
    • true is recommended if you want simplicity, because it'll behave like a server-based cache (it caches copies of plain data).
    • false is recommended if you want to achieve performance or save mutable objects or other complex types with mutability involved and wanted, because it'll only store references of your data.
    • Here's a simple code example showing the different behavior
  • deleteOnExpire: (default: true) whether variables will be deleted automatically when they expire. If true the variable will be deleted. If false the variable will remain. You are encouraged to handle the variable upon the event expired by yourself.
  • enableLegacyCallbacks: (default: false) re-enables the usage of callbacks instead of sync functions. Adds an additional cb argument to each function which resolves to (err, result). will be removed in node-cache v6.x.
  • maxKeys: (default: -1) specifies a maximum amount of keys that can be stored in the cache. If a new item is set and the cache is full, an error is thrown and the key will not be saved in the cache. -1 disables the key limit.
const NodeCache = require( "node-cache" );
const myCache = new NodeCache( { stdTTL: 100, checkperiod: 120 } );

Since 4.1.0: Key-validation: The keys can be given as either string or number, but are casted to a string internally anyway. All other types will throw an error.

Store a key (SET):

myCache.set( key, val, [ ttl ] )

Sets a key value pair. It is possible to define a ttl (in seconds). Returns true on success.

obj = { my: "Special", variable: 42 };

success = myCache.set( "myKey", obj, 10000 );
// true

Note: If the key expires based on it's ttl it will be deleted entirely from the internal data object.

Store multiple keys (MSET):

myCache.mset(Array<{key, val, ttl?}>)

Sets multiple key val pairs. It is possible to define a ttl (seconds). Returns true on success.

const obj = { my: "Special", variable: 42 };
const obj2 = { my: "other special", variable: 1337 };

const success = myCache.mset([
	{key: "myKey", val: obj, ttl: 10000},
	{key: "myKey2", val: obj2},
])

Retrieve a key (GET):

myCache.get( key )

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

value = myCache.get( "myKey" );
if ( value == undefined ){
	// handle miss!
}
// { my: "Special", variable: 42 }

Since 2.0.0:

The return format changed to a simple value and a ENOTFOUND error if not found *( as result instance of Error )

Since 2.1.0:

The return format changed to a simple value, but a due to discussion in #11 a miss shouldn't return an error. So after 2.1.0 a miss returns undefined.

Take a key (TAKE):

myCache.take( key )

get the cached value and remove the key from the cache.
Equivalent to calling get(key) + del(key).
Useful for implementing single use mechanism such as OTP, where once a value is read it will become obsolete.

myCache.set( "myKey", "myValue" )
myCache.has( "myKey" ) // returns true because the key is cached right now
value = myCache.take( "myKey" ) // value === "myValue"; this also deletes the key
myCache.has( "myKey" ) // returns false because the key has been deleted

Get multiple keys (MGET):

myCache.mget( [ key1, key2, ..., keyn ] )

Gets multiple saved values from the cache. Returns an empty object {} if not found or expired. If the value was found it returns an object with the key value pair.

value = myCache.mget( [ "myKeyA", "myKeyB" ] );
/*
	{
		"myKeyA": { my: "Special", variable: 123 },
		"myKeyB": { the: "Glory", answer: 42 }
	}
*/

Since 2.0.0:

The method for mget changed from .get( [ "a", "b" ] ) to .mget( [ "a", "b" ] )

Delete a key (DEL):

myCache.del( key )

Delete a key. Returns the number of deleted entries. A delete will never fail.

value = myCache.del( "A" );
// 1

Delete multiple keys (MDEL):

myCache.del( [ key1, key2, ..., keyn ] )

Delete multiple keys. Returns the number of deleted entries. A delete will never fail.

value = myCache.del( "A" );
// 1

value = myCache.del( [ "B", "C" ] );
// 2

value = myCache.del( [ "A", "B", "C", "D" ] );
// 1 - because A, B and C not exists

Change TTL (TTL):

myCache.ttl( key, ttl )

Redefine the ttl of a key. Returns true if the key has been found and changed. Otherwise returns false. If the ttl-argument isn't passed the default-TTL will be used.

The key will be deleted when passing in a ttl < 0.

myCache = new NodeCache( { stdTTL: 100 } )
changed = myCache.ttl( "existentKey", 100 )
// true

changed2 = myCache.ttl( "missingKey", 100 )
// false

changed3 = myCache.ttl( "existentKey" )
// true

Get TTL (getTTL):

myCache.getTtl( key )

Receive the ttl of a key. You will get:

  • undefined if the key does not exist
  • 0 if this key has no ttl
  • a timestamp in ms representing the time at which the key will expire
myCache = new NodeCache( { stdTTL: 100 } )

// Date.now() = 1456000500000
myCache.set( "ttlKey", "MyExpireData" )
myCache.set( "noTtlKey", "NonExpireData", 0 )

ts = myCache.getTtl( "ttlKey" )
// ts wil be approximately 1456000600000

ts = myCache.getTtl( "ttlKey" )
// ts wil be approximately 1456000600000

ts = myCache.getTtl( "noTtlKey" )
// ts = 0

ts = myCache.getTtl( "unknownKey" )
// ts = undefined

List keys (KEYS)

myCache.keys()

Returns an array of all existing keys.

mykeys = myCache.keys();

console.log( mykeys );
// [ "all", "my", "keys", "foo", "bar" ]

Has key (HAS)

myCache.has( key )

Returns boolean indicating if the key is cached.

exists = myCache.has( 'myKey' );

console.log( exists );

Statistics (STATS):

myCache.getStats()

Returns the statistics.

myCache.getStats();
	/*
		{
			keys: 0,    // global key count
			hits: 0,    // global hit count
			misses: 0,  // global miss count
			ksize: 0,   // global key size count in approximately bytes
			vsize: 0    // global value size count in approximately bytes
		}
	*/

Flush all data (FLUSH):

myCache.flushAll()

Flush all data.

myCache.flushAll();
myCache.getStats();
	/*
		{
			keys: 0,    // global key count
			hits: 0,    // global hit count
			misses: 0,  // global miss count
			ksize: 0,   // global key size count in approximately bytes
			vsize: 0    // global value size count in approximately bytes
		}
	*/

Flush the stats (FLUSH STATS):

myCache.flushStats()

Flush the stats.

myCache.flushStats();
myCache.getStats();
	/*
		{
			keys: 0,    // global key count
			hits: 0,    // global hit count
			misses: 0,  // global miss count
			ksize: 0,   // global key size count in approximately bytes
			vsize: 0    // global value size count in approximately bytes
		}
	*/

Close the cache:

myCache.close()

This will clear the interval timeout which is set on check period option.

myCache.close();

Events

set

Fired when a key has been added or changed. You will get the key and the value as callback argument.

myCache.on( "set", function( key, value ){
	// ... do something ...
});

del

Fired when a key has been removed manually or due to expiry. You will get the key and the deleted value as callback arguments.

myCache.on( "del", function( key, value ){
	// ... do something ...
});

expired

Fired when a key expires. You will get the key and value as callback argument.

myCache.on( "expired", function( key, value ){
	// ... do something ...
});

flush

Fired when the cache has been flushed.

myCache.on( "flush", function(){
	// ... do something ...
});

flush_stats

Fired when the cache stats has been flushed.

myCache.on( "flush_stats", function(){
	// ... do something ...
});

Breaking changes

version 2.x

Due to the Issue #11 the return format of the .get() method has been changed!

Instead of returning an object with the key { "myKey": "myValue" } it returns the value itself "myValue".

version 3.x

Due to the Issue #30 and Issue #27 variables will now be cloned. This could break your code, because for some variable types ( e.g. Promise ) its not possible to clone them. You can disable the cloning by setting the option useClones: false. In this case it's compatible with version 2.x.

version 5.x

Callbacks are deprecated in this version. They are still useable when enabling the enableLegacyCallbacks option when initializing the cache. Callbacks will be completely removed in 6.x.

Compatibility

Node-Cache supports all node versions >= 8

Release History

VersionDateDescription
5.1.12020-06-06[#184], [#183] thanks Jonah Werre for reporting [#181]!, [#180], Thanks Titus for [#169]!, Thanks Ianfeather for [#168]!, Thanks Adam Haglund for [#176]
5.1.02019-12-08Add .take() from PR [#160] and .flushStats from PR [#161]. Thanks to Sujesh Thekkepatt and Gopalakrishna Palem!
5.0.22019-11-17Fixed bug where expired values were deleted even though deleteOnExpire was set to false. Thanks to fielding-wilson!
5.0.12019-10-31Fixed bug where users could not set null values. Thanks to StefanoSega, jwest23 and marudor!
5.0.02019-10-23Remove lodash dependency, add .has(key) and .mset([{key,val,ttl}]) methods to the cache. Thanks to Regev Brody for PR [#132] and Sujesh Thekkepatt for PR [#142]! Also thank you, to all other contributors that remain unnamed here!
4.2.12019-07-22Upgrade lodash to version 4.17.15 to suppress messages about unrelated security vulnerability
4.2.02018-02-01Add options.promiseValueSize for promise value. Thanks to Ryan Roemer for the pull [#84]; Added option deleteOnExpire; Added DefinitelyTyped Typescript definitions. Thanks to Ulf Seltmann for the pulls [#90] and [#92]; Thanks to Daniel Jin for the readme fix in pull [#93]; Optimized test and ci configs.
4.1.12016-12-21fix internal check interval for node < 0.10.25, thats the default node for ubuntu 14.04. Thanks to Jimmy Hwang for the pull #78; added more docker tests
4.1.02016-09-23Added tests for different key types; Added key validation (must be string or number); Fixed .del bug where trying to delete a number key resulted in no deletion at all.
4.0.02016-09-20Updated tests to mocha; Fixed .ttl bug to not delete key on .ttl( key, 0 ). This is also relevant if stdTTL=0. This causes the breaking change to 4.0.0.
3.2.12016-03-21Updated lodash to 4.x.; optimized grunt
3.2.02016-01-29Added method getTtl to get the time when a key expires. See #49
3.1.02016-01-29Added option errorOnMissing to throw/callback an error o a miss during a .get( "key" ). Thanks to David Godfrey for the pull #45. Added docker files and a script to run test on different node versions locally
3.0.12016-01-13Added .unref() to the checkTimeout so until node 0.10 it's not necessary to call .close() when your script is done. Thanks to Doug Moscrop for the pull #44.
3.0.02015-05-29Return a cloned version of the cached element and save a cloned version of a variable. This can be disabled by setting the option useClones:false. (Thanks for #27 to cheshirecatalyst and for #30 to Matthieu Sieben)
2.2.02015-05-27REVOKED VERSION, because of conficts. See Issue #30. So 2.2.0 is now 3.0.0
2.1.12015-04-17Passed old value to the del event. Thanks to Qix for the pull.
2.1.02015-04-17Changed get miss to return undefined instead of an error. Thanks to all #11 contributors
2.0.12015-04-17Added close function (Thanks to ownagedj). Changed the development environment to use grunt.
2.0.02015-01-05changed return format of .get() with a error return on a miss and added the .mget() method. Side effect: Performance of .get() up to 330 times faster!
1.1.02015-01-05added .keys() method to list all existing keys
1.0.32014-11-07fix for setting numeric values. Thanks to kaspars + optimized key ckeck.
1.0.22014-09-17Small change for better ttl handling
1.0.12014-05-22Readme typos. Thanks to mjschranz
1.0.02014-04-09Made callbacks optional. So it's now possible to use a syncron syntax. The old syntax should also work well. Push : Bugfix for the value 0
0.4.12013-10-02Added the value to expired event
0.4.02013-10-02Added nodecache events
0.3.22012-05-31Added Travis tests

NPM

Other projects

NameDescription
rsmqA really simple message queue based on redis
redis-heartbeatPulse a heartbeat to redis. This can be used to detach or attach servers to nginx or similar problems.
systemhealthNode module to run simple custom checks for your machine or it's connections. It will use redis-heartbeat to send the current state to redis.
rsmq-clia terminal client for rsmq
rest-rsmqREST interface for.
redis-sessionsAn advanced session store for NodeJS and Redis
connect-redis-sessionsA connect or express middleware to simply use the redis sessions. With redis sessions you can handle multiple sessions per user_id.
redis-notificationsA redis based notification engine. It implements the rsmq-worker to safely create notifications and recurring reports.
nsq-loggerNsq service to read messages from all topics listed within a list of nsqlookupd services.
nsq-topicsNsq helper to poll a nsqlookupd service for all it's topics and mirror it locally.
nsq-nodesNsq helper to poll a nsqlookupd service for all it's nodes and mirror it locally.
nsq-watchWatch one or many topics for unprocessed messages.
hyperrequestA wrapper around hyperquest to handle the results
task-queue-workerA powerful tool for background processing of tasks that are run by making standard http requests
soyerSoyer is small lib for server side use of Google Closure Templates with node.js.
grunt-soy-compileCompile Goggle Closure Templates ( SOY ) templates including the handling of XLIFF language files.
backlunrA solution to bring Backbone Collections together with the browser fulltext search engine Lunr.js
domelA simple dom helper if you want to get rid of jQuery
obj-schemaSimple module to validate an object by a predefined schema

The MIT License (MIT)

Copyright © 2019 Mathias Peter and the node-cache maintainers, https://github.com/node-cache/node-cache

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

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.