DEV Community

Cover image for Five Design Patterns to know in Node.js

Five Design Patterns to know in Node.js

Jakub Andrzejewski on October 07, 2024

Hey there! I recently went through multiple knowledge resources to learn more about popular design and architectural patterns in Node.js. My aim w...
Read full post
Collapse
 
doronguttman profile image
Doron Guttman •

Trying to be positive here, but these examples leave a lot of room for improvement. I.e.

  1. Singleton: when using modules (which you should), there is no need to use a getInstance static method, when you can just export the instance by itself. E.g. 
export const redis = new Redis(...);
export default redis;
Enter fullscreen mode Exit fullscreen mode
  1. Factory: instead of using a switch, you should be using a factory map. Much more extensible and (although micro) optimized. E.g. 
const factory = FACTORIES[name];
if (!factory) {
  throw...
}
return factory();
Enter fullscreen mode Exit fullscreen mode
  1. Observer: use a Set instead of an array. And wrap notifications in try-catch so a single error won't impact following observers. E.g. 
// Subscribe
this.observers.set(observer);
// Unsubscribe 
this.observers.delete(observer);
// Notify
for (const observer of this.observers) {
  try {
    observer.update(...)
  } catch (e) {
    // Log
  }
}
Enter fullscreen mode Exit fullscreen mode
  1. Decorator: use getters and private fields instead of java-style get methods. E.g. 
get endurance() {
  return this.#endurance;
}
Enter fullscreen mode Exit fullscreen mode
  1. Dependency injection: tip - use an IoC library
Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski •

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 :)

Collapse
 
arnorhs profile image
Arnór Sigurðsson •

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.

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski •

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 :)

Collapse
 
adiozdaniel profile image
adiozdaniel •

I've learned a lot

Collapse
 
kuzjt93 profile image
Long.H • • Edited

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;
}

Collapse
 
doronguttman profile image
Doron Guttman •

You don't, as you are not exporting the classz just the instance, which is the whole point.

Collapse
 
wormss profile image
WORMSS •

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. and instance which is not actually an error, just reads weirdly.

For the Factory pattern, you re-used the variable name for both type of character to create and the name 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 method action.character.getEndurance() but with no explanation of why one and not the other in either scenario. It leaves getEndurance() as completely unnecessary and muddies the water for no advantage.

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski •

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 :(

Collapse
 
marcus-sa profile image
Marcus S. Abildskov • • Edited

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...

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski •

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? :)

Collapse
 
marcus-sa profile image
Marcus S. Abildskov •

You should have a look at deepkit.io that utilizes TypeScript to the fullest.

Collapse
 
kuzjt93 profile image
Long.H •

Nest framework built on top of OOP, I believe

Collapse
 
dsabalete profile image
David Sabalete •

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?

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski •

Damn, good catch!

Gramarly must have corrected this redisOne into medicine.

Thank you for catching that! :)

Collapse
 
joelbonetr profile image
JoelBonetR 🥇 •

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:

joelbonetr

Demystifying Design Patterns

JoelBonetR 🥇 ・ Oct 30

#javascript #webdev #programming #beginners

Cheers!

Collapse
 
aloisseckar profile image
Alois Sečkár •

Article has 5 examples, the perex says 10... 🤨

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski •

Good catch! I initially wanted 10 but decided to decrease it to make it shorter. I will fix it right away! :)

Collapse
 
neatshell profile image
Claudio Stella •

Five design pattern to know in every OOP capable language, should be a less click bait version of the title.

Collapse
 
jacobandrewsky profile image
Jakub Andrzejewski •

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 :)

Collapse
 
manuelsanchez2 profile image
Manuel Sanchez •

Your title is far more click bait than the node one