Your JavaScript / Node Module Would possibly Be A “Singleton” (Anti-Sample)

On this planet of programming, the Singleton design sample is typically criticized as an anti-pattern: it’s not versatile, it makes testing tougher, dependency administration tougher, and violates the single-responsibility precept. Which is why it’s best to attempt to keep away from utilizing the Singleton sample generally. That stated, I think that quite a lot of JavaScript programmers are utilizing the Singleton sample with out even eager about it by co-opting their JavaScript modules as initialization vectors.

Earlier than we have a look at what I imply, it is essential to know that there’s a important — albeit delicate — distinction between a “Single Occasion” and a “Singleton“. Many functions instantiate and cache parts all through an software’s life-cycle. In truth, for a lot of storage libraries and API consumer libraries, that is the creator’s advisable method: create, cache, after which share a thread-safe occasion.

These thread-safe, cached cases are Single cases of a category or part – not Singletons. Sometimes, solely one among them is created throughout the software lifespan as a way to cut back efficiency and reminiscence overhead. Nonetheless, that is tactical determination, not a technical one. That means, a developer might instantiate a number of variations of the identical class if the necessity ever arose. For instance, a number of cases of a Database consumer could possibly be created to be able to learn from totally different datasource names.

Singletons, alternatively, have a technical limitation: just one occasion can ever be created throughout the software, it doesn’t matter what wants come up.

Within the JavaScript / NodeJS ecosystems, I typically see folks by accident falling into the Singleton anti-pattern by commingling two totally different obligations inside their modules:

• Class definition.
• Class instantiation.

What I imply by that is that the module that defines a category additionally takes care of instantiating and exporting that class. Take into account this trite database consumer module:

var instanceID = 0;
var username = course of.env.DB_USERNAME;
var password = course of.env.DB_PASSWORD;
var datasource = course of.env.DB_DATASOURCE;

class DatabaseClient {

	constructor( username, password, datasource ) {

		this.username = username;
		this.password = password;
		this.datasource = datasource;
		this.uid = ++instanceID;

	}

}

// Initialize and export the database consumer.
module.exports.consumer = new DatabaseClient( username, password, datasource );

As you’ll be able to see right here, this module each defines and instantiates the database consumer. Which implies, when the calling code runs, it may possibly import the already created and cached occasion of the DatabaseClient class:

var consumer = require( "./database-client" ).consumer;

// That is the ALREADY INSTANTIATED consumer.
console.log( consumer );

Now, in Node (and I consider in JavaScript as effectively), a module is just ever evaluated as soon as per distinctive import / require path. Which implies, if I had one other file that additionally ran this code throughout the identical software life-span:

var consumer = require( "./database-client" ).consumer

… the runtime would merely use the cached module analysis at that the given path and would due to this fact return the already instantiated consumer variable.

On this software, there’s no method for me to create a number of cases of that DatabaseClient class. Irrespective of what number of instances I attempt to import the consumer, it is at all times the identical, cached occasion. This can be a Singleton.

In truth, not solely is that this a Singleton, but it surely’s additionally affected by one other anti-pattern: it’s tightly coupled the course of.env idea. Discover that once I instantiate the DatabaseClient class inside my module, I am pulling the username, password, and datasource from the atmosphere. So, in all actuality, this module is commingling three totally different obligations:

• Class definition.
• Class instantiation.
• Secrets and techniques administration.

To repair each of those anti-patterns, we have to separate the duty of definition from the duty of instantiation. That is typically completed by having some form of a “predominant” bootstrapping module that imports, instantiates, and caches courses that ought to solely be instantiated as soon as (as a tactical selection, not a technical constraint).

So, as an alternative of our database consumer module instantiating the database consumer, it easy exports the category definition:

var instanceID = 0;

module.exports = class DatabaseClient {

	constructor( username, password, datasource ) {

		this.username = username;
		this.password = password;
		this.datasource = datasource;
		this.uid = ++instanceID;

	}

};

There is no extra coupling to the instantiation logic and no extra coupling to the course of.env secrets and techniques administration. And now, we simply want some form of predominant bootstrapping course of to wire the entire software collectively:

var DatabaseClient = require( "./clean-database-client" );

// Now that the DatabaseClient module is void of any instantiation logic, we are able to draw a
// clear boundary across the logic that's liable for wiring the appliance
// parts collectively. Discover that we have additionally eliminated the tight-coupling to the ENV.
var consumer = new DatabaseClient(
	course of.env.DB_USERNAME,
	course of.env.DB_PASSWORD,
	course of.env.DB_DATASOURCE
);

Proper now, there’s solely a “single occasion” of the DatabaseClient class. However, that is not a singleton. Ought to we have to instantiate a number of cases of the category to be able to learn from totally different datasource names, we are able to simply accomplish that by newing up one other occasion!

After we have instantiated our database consumer, our bootstrapping course of would then present it to different courses by Inversion of Management (IoC). In the identical method that our bootstrapping course of supplied the username, password, and datasource to the DatabaseClient constructor, so to wouldn’t it present the cached consumer occasion as a constructor argument to another module that wants it.

Backside line, when you’re relying on the truth that a module is just ever evaluated as soon as; and also you’re leaning on that technical element to be able to instantiate and cache JavaScript modules; then, you have seemingly fallen into the Singleton anti-pattern. The excellent news is, you will get your self out of that gap by refactoring the category instantiation logic out and right into a centralized location.

Epilogue: It is a State Downside, Not a class Downside

Typically, it isn’t even so clean-cut. For instance, have a look at this Angular code that I wrote the opposite week: it is each exporting a class and pulling from the atmosphere:

// Import software modules.
import { atmosphere } from "~/environments/atmosphere";

@Injectable({
	providedIn: "root"
})
export class ApiClient {

	personal apiDomain: string;
	personal httpClient: HttpClient;

	/**
	* I initialize the API consumer.
	*/
	constructor( httpClient: HttpClient ) {

		this.httpClient = httpClient;

		// TODO: Ought to this be supplied as an injectable? It appears sloppy for a runtime
		// part to be pulling immediately from the atmosphere. This creates tight-
		// coupling to the appliance bootstrapping course of.
		this.apiDomain = atmosphere.apiDomain;

	}

	// .... truncated ....
}

At first look, it’d appear to be I am doing every thing “proper”. However, despite the fact that I am doing my finest to separate considerations, I nonetheless fall into the Singleton lure by leaving the apiDomain state initialization within the module. Sure, I can create a number of cases of the exported ApiClient class; however, they may all solely ever level to the identical apiDomain. Actually, what I have to do is present the apiDomain as a constructor argument to be able to absolutely transfer state initialization out into the bootstrapping course of.

That is the most important downside with the Singleton anti-pattern: it is really easy to make use of. However, the second you do, issues turn out to be tightly coupled and tougher to evolve and preserve.

Need to use code from this put up?
Try the license.