CODEWITHSUNDEEP
node.jsredis
Pono
Pono

Reputation: 11806

Should I share Redis connection between files/modules?

I'm developing a node.js app and I am in need of heavy Redis usage. The app will be clustered across 8 CPU cores.

Right now I have 100 concurrent connections to Redis because every worker per CPU has several modules running require('redis').createClient().

Scenario A:

file1.js:

var redis = require('redis').createClient();

file2.js

var redis = require('redis').createClient();

SCENARIO B:

redis.js

var redis = require('redis').createClient();

module.exports = redis;

file1.js

var redis = require('./redis');

file2.js

var redis = require('./redis');

Which approach is better: creating new Redis instance in every new file I introduce (scenario A) or creating one Redis connection globally (scenario B) and sharing this connection across all modules I have. What are drawbacks/benefits of each solution?

Thanks in advance!

Upvotes: 20

Views: 7835

Answers (3)

Majdi Mohammad
Majdi Mohammad

Reputation: 167

You can create file to handle connection and functions with redis redis-con.js

const redis = require('redis');
let redisClient;
(async () => {
    redisClient = redis.createClient();

    redisClient.on("error", (error) => console.error(`Error Redis: ${error}`));

    await redisClient.connect();
})();

module.exports = redisClient;

Then you need to create function to handle set, get and del.

now, just import the connection

Upvotes: 1

Cody Gustafson
Cody Gustafson

Reputation: 1450

When I face a question such as this I generally think about three basic questions.

  1. Which is more readable?
  2. Which allows better code reuse?
  3. Which is more efficient?

Not necessarily in this order as it depends on the scenario, but I believe in this case all three of these questions are in favor of option B. If you ever needed to modify options for createClient, you would then need to edit them in every file which uses it. Which in option A is every file which uses redis, and option B is just redis.js. Also if a newer or different product comes out and you want to replace redis It would be feasible to make redis.js a wrapper for a different package or even a newer redis client substantially cutting down conversion time.

Globals are generally a bad thing, but in this example redis.js should not be storing mutable state, so there is no problem having a global/singleton in this context.

Upvotes: 6

robertklep
robertklep

Reputation: 203554

Both Node and Redis can handle lots of connections pretty well, so that's not a problem.

In your situation, you're creating Redis connections at the startup of your application, so the number of connections you're setting up is limited (in the sense that after your application is started, the number of connections will be constant).

Situations where you'd want to reuse the same connection is in highly dynamic situations, for instance with an HTTP-server where you need to query Redis for every request. Creating a new connection for each request would be a waste of resources (creating and destroying connections all the time) and reusing one connection for each request would be preferable.

As for which of the two scenario's I'd prefer, I'm leaning towards Scenario A myself.

Upvotes: 1

Related Questions