What is the best way to pass common variables into separate modules in Node.js?

Question

I use separate router files as modules for main app and auth app. I can't get the best way to pass variables(db client) into routers. I don't want to hardcode it or pass it with:

module.exports = function(app, db) {

Maybe it's best way to use singleton register or use global db variable?

What is your experiense with design-patterns? Which way is the best and why?

Answer 1

I have found using dependency injection, to pass things in, to be the best style. It would indeed look something like you have:

// App.js
module.exports = function App() {
};

// Database.js
module.exports = function Database(configuration) {
};

// Routes.js
module.exports = function Routes(app, database) {
};

// server.js: composition root
var App = require("./App");
var Database = require("./Database");
var Routes = require("./Routes");
var dbConfig = require("./dbconfig.json");

var app = new App();
var database = new Database(dbConfig);
var routes = new Routes(app, database);

// Use routes.

This has a number of benefits:

• It forces you to separate your system into components with clear dependencies, instead of hiding the dependencies somewhere in the middle of the file where they call require("databaseSingleton") or worse, global.database.
• It makes unit testing very easy: if I want to test Routes in isolation, I can inject it with fake app and database params and test only the Routes code itself.
• It puts all your object-graph wiring together in a single place, namely the composition root (which in this case is server.js, the app entry point). This gives you a single place to look to see how everything fits together in the system.

One of the better explanations for this that I've seen is an interview with Mark Seeman, author of the excellent book Dependency Injection in .NET. It applies just as much to JavaScript, and especially to Node.js: require is often used as a classic service locator, instead of just a module system.

Answer 2

I suggest you create a settings file with db instance and with other things which you need use globally like 'singleton'.

For example, I have settings.js with my redis db client:

var redis = require('redis');
exports.redis = redis.createClient(6379, '127.0.0.1');

And in other multiple modules I include it:

var settings = require('./settings');
setting.redis.<...>

Many time including it I always have one instance of db connection.

Answer 3

You can save yourself all the boilerplate code of wiring up your modules if you use a dependency injection framework

This answer lists a few of them. I also built a simpler DI framework here.

EDIT: below is a copy form the answer in case that page changes

---

require is the way of managing dependencies in Node.js and surely it is intuitive and effective, but it has also its limitations.

My advice is to take a look at some of the Dependency Injection containers available today for Node.js to have an idea on what are their pros/cons. Some of them are:

• Scatter
• Electrolyte
• Wire
• Intravenous
• Pongular

Just to name a few.

Now the real question is, what can you achieve with a Node.js DI container, compared to a simple require?

Pros:

• better testability: modules accepts their dependencies as input
• Inversion of Control: decide how to wire your modules without touching the main code of your application.
• a customizable algorithm for resolving modules: dependencies have "virtual" identifiers, usually they are not bound to a path on the filesystem.
• Better extensibility: enabled by IoC and "virtual" identifiers.
• Other fancy stuff possible:
  • Async initialization
  • Module lifecycle management
  • Extensibility of the DI container itself
  • Can easily implement higher level abstractions (e.g. AOP)

Cons:

• Different from the Node.js "experience": not using require definitely feels like you are deviating from the Node way of thinking.
• The relationship between a dependency and its implementation is not always explicit. A dependency may be resolved at runtime and influenced by various parameters. The code becomes more difficult to understand and debug
• Slower startup time
• Maturity (at the moment): none of the current solutions is really popular at the moment, so not so many tutorials, no ecosystem, not battle tested.
• Some DI containers will not play well with module bundlers like Browserify and Webpack.

Answer 4

It is completely outdated, but you can use global in a script :

 global.foo = new Foo();

in another script :

 foo.bar();

You can also use already existing constant :

 Object.foo = new Foo();

And here :

 Object.foo.bar();