0

In a Node project with many .js files, suppose I have a file that manages expensive state: it provides a json blob that it regularly fetches from the web in short intervals. Its data is cached and is requested internally far more than its update interval. 

let provider = require('./config-provider.js');
let config = provider.get(); // returns locally cached JSON blob

Suppose the above code exists in 10 different files in my application. This is going to create 10 different instances of this updater, all making expensive web calls to update the config.

I would like to reference a single instance of this config provider across my app. However, this seems to break the modular design of Node apps.

I could always use a global object, but this is obviously frowned upon.

Another solution is to make a complex web of parent / child references across my application. This also seems messy.

Is there some suggested best practice for referencing a single stateful module across the span of one's Node application?

dthree
  • 19,847
  • 14
  • 77
  • 106

1 Answers1

1

In this case you should use the "singleton" pattern as described here. I also find this code example useful. Notice that some developers frown upon singletons in Node JS as discussed here.

Regardless, this pattern makes sense in your case, as you said:

I would like to reference a single instance of this config provider across my app

Other Important Consideration

Besides coding, when you deploy your application to production, you have to consider if you want this single instance replicated as well. For example, if you deploy 3 Node JS instances, do you still want a single instance handling all your JSON blobs? Or is it OK to have it replicated 3 times as well?

A while back I had a scheduling module deployed with 5 Node JS instances. Obviously I couldn't have the scheduler fire the same job 5 times, so it had its own separate instance AND the scheduling module itself was a singleton. I bring this up because there's a clear distinction between singleton objects and how Node JS can be deployed multiple times.

I hope this helps.

Community
  • 1
  • 1
arnold
  • 735
  • 1
  • 7
  • 14
  • 1
    Thanks! Yeah - it looks like `singleton` is the best bet. It's just unfortunate as it doesn't look like there's a single pattern that *isnt* frowned upon by someone. – dthree Sep 14 '15 at 18:47
  • On the scaling point, this isn't a problem - I'm building a large CLI app in Node, so it's just going to be the user instantiating it once. I don't think this is a problem on large-scale web projects, as state is usually stored separately, such as by using `redis`. In that case, there's no incentive for keeping state in your Node app. I am not going to require an external data store, however, for a CLI app! – dthree Sep 14 '15 at 18:49
  • Based on what you said, it makes sense. It's just worth adding that singletons work best with mostly read-only data. If multiple async processes start writing to the same object several times, maintaining a consistent state becomes a consideration. However, this doesn't seem to be an issue in your case. Good luck! – arnold Sep 14 '15 at 19:02