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

On this planet of programming, the Singleton design sample is usually criticized as an anti-pattern: it’s not versatile, it makes testing more durable, dependency administration more durable, and violates the single-responsibility precept. Which is why it’s best to attempt to keep away from utilizing the Singleton sample usually. That mentioned, I think that quite a lot of JavaScript programmers are utilizing the Singleton sample with out even serious 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 vital — albeit refined — distinction between a “Single Occasion” and a “Singleton“. Many functions instantiate and cache parts at some point of an software’s life-cycle. In reality, for a lot of storage libraries and API consumer libraries, that is the writer’s really useful strategy: create, cache, after which share a thread-safe occasion.

These thread-safe, cached situations are Single situations of a category or element – not Singletons. Usually, solely considered one of them is created in the course of the software lifespan as a way to scale back efficiency and reminiscence overhead. Nevertheless, that is tactical choice, 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 situations of a Database consumer could possibly be created as a way to learn from completely 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 usually see folks by accident falling into the Singleton anti-pattern by commingling two completely 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. Contemplate 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 may see right here, this module each defines and instantiates the database consumer. Which implies, when the calling code runs, it may 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 imagine 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 subsequently return the already instantiated consumer variable.

On this software, there may be no means for me to create a number of situations 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. It is a Singleton.

In reality, not solely is that this a Singleton, however it’s additionally affected by one other anti-pattern: it’s tightly coupled the course of.env idea. Discover that after 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 completely different obligations:

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

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

So, as a substitute 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 important 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 will 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 situations of the category as a way to learn from completely different datasource names, we will 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 lessons by way of Inversion of Management (IoC). In the identical means that our bootstrapping course of offered the username, password, and datasource to the DatabaseClient constructor, so to would it not present the cached consumer occasion as a constructor argument to every other module that wants it.

Backside line, for those who’re relying on the truth that a module is just ever evaluated as soon as; and also you’re leaning on that technical element as a way to instantiate and cache JavaScript modules; then, you’ve got probably 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

Generally, it is not 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 offered as an injectable? It appears sloppy for a runtime
		// element to be pulling straight from the atmosphere. This creates tight-
		// coupling to the appliance bootstrapping course of.
		this.apiDomain = atmosphere.apiDomain;

	}

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

At first look, it’d seem like I am doing the whole lot “proper”. However, regardless 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 situations of the exported ApiClient class; however, they’ll all solely ever level to the identical apiDomain. Actually, what I have to do is present the apiDomain as a constructor argument as a way to totally transfer state initialization out into the bootstrapping course of.

That is the largest drawback with the Singleton anti-pattern: it is really easy to make use of. However, the second you do, issues change into tightly coupled and more durable to evolve and keep.

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