Hey there!
I recently went through multiple knowledge resources to learn more about popular design and architectural patterns in Node.js. My aim was mainly at the server (backend) side but as I was going through them, I was seeing a lot of similarities to the browser (frontend) frameworks. Some of them are even directly used in the frameworks for which I am even more happy because I was using them already without knowing it 😉
There are many (really many) design patterns that you could use, so in this article, I decided to choose 5 of them and explain them in more detail.
Enjoy!
🟢 What is a Design Pattern?
Design patterns are proven and battle-tested solutions to solve problems that we as developers encounter every day. These patterns help promote best practices and implement a structured approach to solving everyday issues while designing and developing software architecture. Software engineers can develop maintainable, secure, and stable systems by using these patterns.
Node.js due to its flexibility does not force you to stick to certain patterns but instead gives you the freedom of choosing just the ones needed for your task. That is why in my opinion it is so widely used today (and by the way thanks to JavaScript :D).
✅ Five Popular Design Patterns in Node.js
Below, you will see a list of 5 selected design patterns that I like.
Singleton
This pattern is all about classes that can have only one instance and provide global access to it. Modules can be cached and shared across the application in Node.js which will help improve the efficiency of resources. A common example of such a singleton pattern is a module for connecting with certain third-party services like databases, cache services, email providers, etc that is used extensively in the Nest.js framework. Let's take a look at the following example:
class Redis {
constructor() {
this.connection = null;
}
static getInstance() {
if (!Redis.instance) {
Redis.instance = new Redis(options);
}
return Redis.instance;
}
connect() {
this.connection = 'Redis connected'
}
}
And then we can use it like the following:
const redisOne = Redis.getInstance();
const redisTwo = Redis.getInstance();
console.log(redisOne === redisTwo); // it will result to `true`
redisOne.connect();
console.log(redisOne.connection) // 'Redis connected'
console.log(redisTwo.connection) // 'Redis connected'
This approach ensures that there is only one connection to Redis and prevents duplicating connections.
Factory
With this pattern, you can create new objects without specifying the class of object that will be created. Thanks to it we are abstracting object creation which can help improve code readability and reusability:
class Character {
constructor(type, health) {
this.type = type;
this.health = health;
}
}
class CharacterFactory {
createCharacter(name) {
switch(name) {
case 'mage':
return new Character('Powerful Mage', 8);
case 'warrior':
return new Character('Courageous Warrior', 10);
case 'rogue':
return new Character('Sneaky Rogue', 9)
default:
return new Error('Unknown character');
}
}
}
And then we can use it like the following:
const characterFactory = new CharacterFactory();
const mage = characterFactory.createCharacter('mage');
const warrior = characterFactory.createCharacter('warrior');
console.log(mage.type) // Powerful Mage
console.log(warrior.type) // Courageous Warrior
This approach allows consumers of this factory to use the factory code instead of using the Character class constructor directly.
Observer
This pattern works in a way that you will have an entity that manages the list of depending elements called observers and notifies them if the state changes. This pattern is used widely in the Vue.js framework and be implemented like this:
class Topic {
constructor() {
this.observers = [];
}
subscribe(observer) {
this.observers.push(observer);
}
unsubscribe(observer) {
this.observers = this.observers.filter(o => o !== observer);
}
notify(data) {
this.observers.forEach(o => o.update(data));
}
}
class Observer {
constructor(name) {
this.name = name;
}
update(data) {
console.log(`${this.name} received ${data}`);
}
}
And you can use it like the following:
const topic = new Topic();
const observer1 = new Observer('Observer 1');
const observer2 = new Observer('Observer 2');
topic.subscribe(observer1);
topic.subscribe(observer2);
topic.notify('Hello World');
// Observer 1 received Hello World
// Observer 2 received Hello World
topic.unsubscribe(observer2);
topic.notify('Hello Again');
// Observer 1 received Hello Again
It is a really useful pattern for event handling and asynchronous workflows that allows to update of multiple objects without coupling the publisher to the subscribers.
Decorator
This pattern is quite useful for extending the existing functionality with a new one without affecting the initial/original instances. It is used widely in the Nest.js framework thanks to the full support of TypeScript but in regular Node.js it can be used in following:
class Character {
constructor() {
this.endurance = 10;
}
getEndurance() {
return this.endurance;
}
}
class CharacterActions {
constructor(character) {
this.character = character;
}
attack() {
this.character.endurance -= 2;
}
rest() {
this.character.endurance += 1;
}
}
And then it can be used like the following:
const character = new Character();
console.log(character.getEndurance()); // 10
const characterWithActions = new CharacterActions(character);
characterWithActions.attack(); // - 2
characterWithActions.rest(); // + 1
console.log(characterWithActions.character.getEndurance()); // 9
By using this pattern we can easily extend already existing classes without affecting their core functionality.
Dependency Injection
In this pattern, classes or modules receive dependencies from external sources rather than registering them internally. This approach allows extracting certain reusable elements from your system for easier testing and maintenance. It is used quite extensively in the Nest.js framework. It can be implemented like following:
class UserService {
constructor(databaseService, loggerService) {
this.db = databaseService;
this.logger = loggerService;
}
async getUser(userId) {
const user = await this.db.findUserById(userId);
this.logger.log(`Fetched user ${user.name}`);
return user;
}
}
And then, you can use it like following:
const databaseService = new Database();
const loggerService = new Logger();
const userService = new UserService(databaseService, loggerService);
userService.getUser(1);
This approach allows you to extract elements of your system into intependent entities that can be injected when needed.
📖 Learn more
If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, check VueSchool by clicking this link or by clicking the image below:
It covers the most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉
✅ Summary
Well done! You have just learned how certain design patterns work in Node.js and how to implement them.
Take care and see you next time!
And happy coding as always 🖥️
Top comments (21)
Trying to be positive here, but these examples leave a lot of room for improvement. I.e.
getInstance
static method, when you can just export the instance by itself. E.g.Hey there. Thanks for these additional examples!
I do agree that my examples are not perfect. I have selected them for simplicity while trying to explain the subject. For anyone who will be reading it and looking for something more optimized and advanced will see your comment and will be able to use it :)
I agree on most points. The factory one is more like a preference thing - I usually use the object map approach you suggested, rather than a switch statement, but I'd still consider that a preference.
Re: observer.. sure.. but since the article's title is like it's aimed at node.js, it's insane to not talk about EventEmitter - it's the de-facto pub-sub thing to use in node.js and it is used so much in almost every single project - most people won't implement their own observer thing - they'll just use EventEmitter - so that is the most valualble feedback to give on that front.
And regarding decorators.. dude, the state of decorators is in shambles.. I would strongly discourage people from using decorators as much as possible until they become part of standard ecmascript -- they're at stage 3 right now, and with all the differing interfacing between typescript and node.js transpilation etc.. it's a mess better left out if possible.
I do realize a lot of frameworks use them by using the legacy decorator transpilation stuff, but to me that is just an ugly mess, and I'd rather just write plain code until they are fully standardized.
Hey there,
Thanks for this comment and additional details! Viewers can now see it and get more examples and start using it in their projects :)
I've learned a lot
export const redis = new Redis(...);
export default redis;
With this, I think we need to fix the constructor to make sure new Instance are not created?
constructor() {
if (Redis.instance) {
return Redis.instance;
}
Redis.instance = this;
}
You don't, as you are not exporting the classz just the instance, which is the whole point.
You may want to test some of your examples.
You have an error in the first one with capitalising
Return
this will cause an error.Also, you have a space between
Redis.
andinstance
which is not actually an error, just reads weirdly.For the Factory pattern, you re-used the variable
name
for bothtype
of character to create and thename
of the created character.This will obviously work, but just muddies the water for any new developer, and there is not a single advantage to doing so.
You use both direct variable access,
character.endurance
and getter methodaction.character.getEndurance()
but with no explanation of why one and not the other in either scenario. It leavesgetEndurance()
as completely unnecessary and muddies the water for no advantage.Hey, thank you so much for pointing that out. I fixed first two issues but not sure about the third one. Could you please elaborate which part does not make sense to you? I am not sure what to rewrite :(
What has this got to do with Node or JavaScript? Those are common patterns in any language capable of OOP.
Also the decorator pattern can be very confusing when decorators are typical known for something else in JavaScript...
In the article, I mentioned few times that some of these patterns could be observed in frameworks such as Nest.js - I am using this framework on the daily basis and while it is built using TypeScript it is technically Node.js application with Express framework.
I wanted to share some of these patterns that could be used for regular Node.js as well. You can also build Node.js applications with TypeScript -> nodejs.org/en/learn/typescript/int...
I do agree that the decorator pattern could be missleading. Would you recommend to adding a note there that it only applies to Node.js apps built with TypeScript? :)
You should have a look at deepkit.io that utilizes TypeScript to the fullest.
Nest framework built on top of OOP, I believe
Good description of these common 5 patterns. Thank you!
P.S.: In the singleton example, the first "redis" instance is declared as
const medicine = Redis.getInstance();
I'm sure you mean
const redisOne = Redis.getInstance();
don't you?
Damn, good catch!
Gramarly must have corrected this redisOne into medicine.
Thank you for catching that! :)
This post is a cool learning experiment 💪🏼 though I feel like it's necessary to explain that there's no real need for most design patterns mentioned here, specially in JavaScript, a multi-paradigm language.
This might help giving context to beginners:
Demystifying Design Patterns
JoelBonetR 🥇 ・ Oct 30
Cheers!
Article has 5 examples, the perex says 10... 🤨
Good catch! I initially wanted 10 but decided to decrease it to make it shorter. I will fix it right away! :)
Five design pattern to know in every OOP capable language, should be a less click bait version of the title.
Correct, but honestly I was not aiming for click baiting. Node.js is my area of expertise and these design patterns I managed to use by building applications with Nest.js and Nuxt (Vue) where TypeScript is use :)
Your title is far more click bait than the node one