CODEWITHSUNDEEP
javascriptnode.js
Gherman
Gherman

Reputation: 7436

Is it safe to rely on Node.js require behavior to implement Singletons?

Suppose I have a module implemented like this:

const dbLib = require('db-lib');
const dbConfig = require('db-config');

const dbInstance = dbLib.createInstance({
  host: dbConfig.host,
  database: dbConfig.database,
  user: dbConfig.user,
  password: dbConfig.password,
});

module.exports = dbInstance;

Here an instance of database connection pool is created and exported. Then suppose db-instance.js is required several times throughout the app. Node.js should execute its code only once and always pass the same one instance of database pool. Is it safe to rely on this behavior of Node.js require command? I want to use it so that I don't need to implement dependency injection.

Upvotes: 2

Views: 361

Answers (2)

axiac
axiac

Reputation: 72266

The documentation of Node.js about modules explains:

Modules are cached after the first time they are loaded. This means (among other things) that every call to require('foo') will get exactly the same object returned, if it would resolve to the same file.

Multiple calls to require('foo') may not cause the module code to be executed multiple times.

It is also worth mentioning the situations when require produce Singletons and when this goal could not reached (and why):

Modules are cached based on their resolved filename. Since modules may resolve to a different filename based on the location of the calling module (loading from node_modules folders), it is not a guarantee that require('foo') will always return the exact same object, if it would resolve to different files.

Additionally, on case-insensitive file systems or operating systems, different resolved filenames can point to the same file, but the cache will still treat them as different modules and will reload the file multiple times. For example, require('./foo') and require('./FOO') return two different objects, irrespective of whether or not ./foo and ./FOO are the same file.

To summarize, if your module name is unique inside the project then you'll always get Singletons. Otherwise, when there are two modules having the same name, require-ing that name in different places may produce different objects. To ensure they produce the same object (the desired Singleton) you have to refer the module in a manner that is resolved to the same file in both places.

You can use require.resolve() to find out the exact file that is resolved by a require statement.

Upvotes: 1

libik
libik

Reputation: 23049

Every single file that you require in Node.js is Singleton.

Also - require is synchronous operation and it also works deterministically. This means it is predictable and will always work the same.

This behaviour is not for require only - Node.js has only one thread in Event-Loop and it works like this (little simplified):

  • Look if there is any task that it can do
  • Take the task
  • Run the task synchronously from the beginning to the end
  • If there are any asynchronous calls, it just push them to "do later", but it never starts them before synchronous part of the task is done (unless there is worker spawned, but you dont need to know details about this)
  • Repeat the whole process

For example imagine this code is file infinite.js:

setTimeout(() => {
   while(true){
      console.log('only this');
   }
}, 1000)

setTimeout(() => {
   while(true){
      console.log('never this');
   }
}, 2000)

while(someConditionThatTakes5000Miliseconds){
   console.log('requiring');
}

When you require this file, it first register to "doLater" the first setTimeout to "after 1000ms be resolved", the second for "after 2000ms be resolved" (note that it is not "run after 1000ms").

Then it run the while cycle for 5000ms (if there is condition like that) and nothing else happens in your code.

After 5000ms the require is completed, the synchronous part is finished and Event Loop looks for new task to do. And the first one to see is the setTimeout with 1000ms delay (once again - it took 1000ms to just mark as "can be taken by Event-Loop", but you dont know when it will be run).

There is neverending while cycle, so you will see in console "only this". The second setTimeout will never be taken from Event-Loop as it is marked after 2000ms to "can be taken", but Event Loop is stuck in never-ending while loop already.

With this knowledge, you can use require (and other Node.js aspects) very confidently.

Conclusion - the require is synchronous, deterministic. Once it finishes with requiring file (the output of it is a object with methods and properties you export, or empty object if you dont export anything) the reference to this object is saved to Node.js core memory. When you require file from somewhere else, it firsts look into the core memory and if it finds the require there, it just use the reference to the object and therefore never execute it twice.

POC:

Create file infinite.js

const time = Date.now();

setTimeout(() => {
    let i=0;
    console.log('Now I get stuck');
    while(true){
       i++;
       if (i % 100000000 === 0) {
           console.log(i);
       }
    }
    console.log('Never reach this');
 }, 1000)

 setTimeout(() => {
    while(true){
       console.log('never this');
    }
 }, 2000)

console.log('Prepare for 5sec wait')
while(new Date() < new Date(time + 5*1000)){
    // blocked
}
console.log('Done, lets allow other')

Then create server.js in same folder with

console.log('start program');
require('./infinite');
console.log('done with requiring');

Run it with node server

This will be the output(with numbers neverending):

start program
Prepare for 5sec wait
Done, lets allow other
done with requiring
Now I get stuck
100000000
200000000
300000000
400000000
500000000
600000000
700000000
800000000
900000000

Upvotes: 2

Related Questions