#include <iostream>

int main()
{
    std::cout << "Let The Performance Begin!\n";
    return 0;
}

به عنوان برنامه نویس BackEnd شما صرفا نباید یک framework developer باشید. باید به درجه ای برسید که بیت به بیت دیتایی که دارید کار باهاش انجام میدید رو بشمارید.
برای رسیدن به همچین سطحی که برای بهینه کردن در حد Bit و Byte صرفا فقط کد زدن و یاد گرفتن زبان و فریمورک جدید کافی نیست. باید در مسیری قدم بزاری که این روزا کمتر آدمایی قدم میزارن. یعنی باید با عینک علمی تر و حتی شاید خننده دار باشه ولی فلسفی تر نگاه کرد.

یک سری کلمات پایه ای وجود داره که نقطه شروع برای رسیدن به همچین نقطه ای هست. این کلمات رو در مطالب من زیاد خواهید دید و هرکدوم رو در تایم مناسب توضیح میدم.

کلا ذات هر سیستم نرم افزاری بسیار بسیار شکننده هست. برای این که نرم افزار ما از این شکنندگی خارج شود باید ( تاکید میکنم باید ) این نکات رو بدونیم.

یک نکته ای هم بگم که شما میتونید تا ابد یک framework developer باشید با درامد خیلی عالی در کشور های تاپ دنیا و هیجی از این نکات هم ندونید.

این فقط عطش یادگیری هست که مثل بنزین در این مسیر به شما انرژی میده که رو به جلو قدم بردارید.

یک سری از موضوعاتی که در این مورد ساعت ها خواهیم وقت گذاشت از این قبیل هستند :
- Compile time vs Runtime
- Dynamic typing vs. static typing
- Strong and weak typing
- Runtime errors vs compile time errors
- Compile time and Runtime Polymorphism
همین الان چند بار در این لیست کوتاه که تیتر وار اشاره کردم کلمه Runtime و Compile time چند بار تکرار شد که اهمیت بالای این موضوع رو نشون میده.
وقتی که بتونید کدتون رو با این عینک که چه تاثیری در Runtime یا Compiletime برنامه میتونه داشته باشه فارغ از زبان برنامه نویسی ببینید.
خودتون اون روز متوجه حرف من خواهید شد که چه تاثیری در استایل کد زدن شما خواهد داشت.

الان حضور ذهن ندارم ولی از این دسته موضوعات کم نیست و این که باهم عمیق به هرکدوم نگاه میکنیم.

دونستن این جنس نکات اعتماد به نفستون رو در مصاحبه بالا میبره و حتی میتونید شخص مصاحبه کننده رو به چالش بکشونید.

صرفا اینجا خوشم نمیاد یک تیکه کد بزارم بگم این فلان کار رو میکنه و تمام.
اینجا عمیق همیشه دوتا سوال رو برسی میکنیم.

۱.چیست؟
۲.چرا؟


#TIP

کتاب درمورد #Golang میخوندم و این پارگراف یکی از زیباترین متن هایی بود که تا حالا دیدم.
درمورد مفهومی وارد شده از دنیای مسابقات اتومبیل رانی به دنیای نرم افزار به اسم mechanical sympathy صحبت میکنه و میگه راننده ای که دقیق با جزیات میدونه ماشینش چطور کار میکنه میتونه تا آخرین ذره قدرت ماشینش رو بکشه بیرون.
حالا شما کلمه "راننده" رو با "برنامه نویس" و ماشین رو با "زبان برنامه نویسی" یا "Runtime env" یا کلمات دیگ جایگزین کن.

و در اخر هم شخصی به اسم Martin Thompson در سال 2011 این موضوع رو سعی کرد در دنیا برنامه نویسی اجرا کنه.

اگر کجکاوی بیشتر دارید اینجا میتونید سر بزنید.

https://mechanical-sympathy.blogspot.com/

بزارید با یک خلاصه از Deno شروع کنیم.
کلا Deno هم مثل Node یک Runtime Environment هست که شما کد جاوا اسکریپت مینویسی و با استفاده از API هایی که Deno در دسترس شما قرار میده میتوانید با سیستم عامل ارتباط بگیرید.
مثل ایجاد HTTP Server یا TCP Socket یا خواندن و نوشتن فایل.

از ویژگی های مثبت Deno بخوام بگم موضوعات زیر هست.
- سرعت بالاتری که نسبت به Node داره.
- با استفاده از permission سیستمی که داره امنیت خیلی زیادی به پروژه های شما میده که Node در نسخه 20 LTS سعی کرد این ویژگی رو که از Deno الهام گرفته اجرا کنه
مثال :
شما یک فایل myfile.txt دارید که یک متن داخلش نوشته شده و میخواید از روی دیسک بخونید.

// main.ts
const result = Deno.readTextFileSync("myfile.txt");
console.log(result);

با دستور زیر اگر بخواید برنامه رو run کنید

deno run main.ts

ازتون میپرسه که آیا به برنامه اجازه خوندن فایل روی دیسک با جزیات دقیق میدی یا خیر که با وارد کردن Y همه چی اوکی میشه.

Deno requests read access to "myfile.txt".
├ Requested by `Deno.readFileSync()` API.
├ Run again with --allow-read to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) > y

حالا شاید این موضوع احمقانه بنظر برسه ولی اگر یک پکیج که یک شخص ناشناس نوشته و شما از npm نصب بکنید اگر بخواد خراب کاری کنه بهتون خبر میده و متوجه میشید و قبلا این موضوع در node خیلی مشکلات امنیتی ایجاد کرده بود.
البته حالا node هم همین ویژگی رو داره اوکی میکنه.
https://news.1rj.ru/str/NodeMaster/7
- موضوع بعدی این که به راحتی #TypeScript رو اجرا میکنه و نیازی به transpile کردن به js برای اجرا نداره و خودش مستقیم ts رو اجرا میکنه. مثل ts-node.
- نکته بعدی این که سعی بر این شده که از Web api های استاندارد برای interface شدن با api های سیستم عامل استفاده بشه که این میتونه مزیت خوبی باشه به این دلیل که اگر web api های js رو بلد باشین اینجا نیازی نیست چیز جدیدی یاد بگیرید.
- موضوع بعدی این که از پکیج های npm هم میتوانید داخل deno استفاده کنید. پکیج های npm که برای node توسعه داده شدند سرعت کمتری نسبت به پکیج های native خود deno دارند و این که مشکلاتی هم از نظر سازاگاری هست. درکل در بهترین حالت این هست که برنامتون کامل از api های deno استفاده کنه.
- به راحتی میتونید از برنامتون خروجی Single executable بگیرید با دستور و روی هر پلتفرمی اجرا کنید.

deno compile main.ts

به عنوان مثال یک http web server در deno
```json

{
  "name": "Node Master",
  "author": "imanhpr"
}
```

```javanoscript
import user from "./user.json" with {type : "json"};

Deno.serve({port : 3005} , (req) => {
  return new Response(JSON.stringify(user))
})

```
به این تکه کد شما یک http server برای پروداکشن دارید با پرفرومنس بالا.

از نکات منفی Deno بخوام بگم
- کامینیوتی کوچک
- پکیج های 3rd party کم
- کمبود منابع آموزشی.
در کل Deno برای با تجربه تر ها خوبه و برای تازه کار خوب نیست بازار کارش مشخص نیست و صرفا به عنوان سرگرمی باید بهش نگاه کرد هرچند پتانسیل خوبی داره و اینجا لیست کوچیکی از ویژگی هاش رو گفتم.
باهاش چنتا برنامه سعی میکنیم بنویسم و یکم نگاهی بهش بندازیم.

مفهوم CPS Style چیست و در NodeJs به چه صورت هست؟
خب دوستان همین الان بگم که خیلی از افرادی که با Node کار کردن تمام مدت از این استایل استفاده کردن حتی بدون این که اسمش رو بدونن.
بزارید با مثال و کد توضیح بدم خیلی راحت متوجه میشید.

function doSomething() {
  return "Something important"
}

در این کد خیلی ساده وقتی ما به صورت مستقیم یک مقداری رو مستقیم return میکنیم به این میگن Direct Style یا استایل مستقیم.
حالا بریم سراغ CPS که در زبان های فانکشنال خیلی مرسوم هست و در Node هم این استایل زیاد دیده میشه مخصوصا api های قدیمی Callback base async

function doSomething(done) {
  done("Something important");
}

function print(str) {
  console.log(str);
}

doSomething(print);

در این برنامه ساده ما یک فاکشن داریم به اسم doSomething که یک فانکشن رو به عنوان رفرنس ورودی میگیره و بعد بجا return کردن خروجی نتیجه رو به عنوان arg با فانکشن done کال میکنه.
فانکشن print هم یک متن ورودی میگیره و صرفا لاگ میکنه
این همون callback عادی خودمون هست ولی خب با عینک علمی تر یک پترنی هست به اسم cps style که گاهی پیش میاد کلی callback تو در تو داشته باشیم.
بد بودن یا خوب بودن این موضوع در اینجا مهم نیست چون بحث سر این زیاده داخل Node.

خودتون قطعا این مورد رو میدونید ولی من میخواستم شما رو با استایل و پترنش آشنا کنم چون در یکی دو پست آینده چنتا کد میخوام معرفی کنم و این مقدمه اونا هست.

در حال حاظر NodeJs برای هرکاری 3 API گاهی هم 2 API در دسترس شما قرار میده تا کارتون رو انجام بدید.
به مثال زیر دقت کنید.

import { readFile as readFileCps, readFileSync } from "node:fs";
import { readFile as readFilePromise } from "node:fs/promises";

// Sync api - Direct style.
const syncRead = readFileSync("myfile.txt", "utf-8");
console.log("1.", syncRead);

// Async api - CPS style.
readFileCps("myfile.txt", "utf-8", (err, data) => {
  if (err) process.exit(1);
  console.log("2.", data);
});

// Async Promise api - looks like sync style - await syntax
const asyncRead = await readFilePromise("myfile.txt", "utf-8");
console.log("3.", asyncRead);

// Async Promise api - looks like CPS style.
readFilePromise("myfile.txt", "utf-8").then((data) => console.log("4.", data));

کلا دقیقا داریم یک کار میکنیم خوندن فایل با استایل های مختلف که خود Node بهمون داده.
اولی به صورت Direct style هست و این عملیات Sync هست و یجاهایی مثلا برای load کردن config فایل کاربرد داره و به هیچ عنوان در http server این رو استفاده نکنید مگر این که دقیق میدونید کجا استفاده کنید.

دومین api که node به ما میده async از طریق cps استایل که node تضمین میکنه به صورت async کد شما اجرا میشه و اصولا async cps syle جز api های قدیمی async در node هستن. قبل از این که promise بیاد همیشه از اینا استفاده میشد.

سومی و چهارمی دقیقا یک شکل هستن اون پشت فقط ظاهرشون فرق میکنه و در خوانایی کد تاثیر داره و گاهی در شرایط خاص فقط از یکیشون میشه استفاده کرد.
هردو جز api های async در node هستن که با promise ها کار میکنند. از وقتی که Promise api ها وارد node شدن CPS style کمرنگ تر شد.

تمام این قصه ها رو گفتم تا برسم به اینجا که.
هنوز هم کد هایی در NodeJs وجود داره که CPS style هستند و معادل Promise API ندارند.
گاهی شما برای کارتون نیاز دارید که این CPS Style ها رو تبدیل کنید به Promise Api و حتی گاهی برعکس.
برای همین میخوام بهتون یک تکنیک نشون بدم با مثال کاربردی که چطور این کار رو انجام بدیم.
در این مدت هم اگر دوست داشتید فکر کنید ببینید خودتون میتونید چیزی پیدا کنید؟

برای پست های جدید کامنت هم باز شد.
اگر سوالی یا نظری داشتید خوشحال میشم کامنت هاتون رو ببینم.
و این که pv منم هرکی حس کرد کمکی از دست من بر میاد میتونه پیام بده

لطفا زیر این پست اگر نظری یا سوالی دارید.
کنجکاوی و پیشنهادی دارید.
ایده بهم بدید تا براتون راجع بهش توضیح بدم.
البته ادامه مفاهیم خودمون هم داریم

خب پیرو سوالی که در اینجا گفتم امیدوارم خودتون اگر کنجکاوی کردین به نتیجه رسیده باشید.
در کتاب خانه

node:util

دوتا فانکشن وجود داره به اسم callbackify و promisify که کار این دو فانکشن این هست که CPS style رو تبدیل میکنه به Promise api و برعکس و نحوه کار کرد این دوتا رو الان میبینیم

import { callbackify } from "node:util";

// Promise to CPS
async function myJob() {
  return "this is a result";
}

const cpsMyJob = callbackify(myJob);
cpsMyJob((err, result) => console.log("in cps :", result));

در این مثال ما یک فانکشن async داریم که خب همیشه یک Promise به ما میده و مشخصه. حالا جایی نیاز داریم که این رو تبدیل کنیم به CPS Style و با استفاده از فانکشن callbackify میتونیم نسخه CPS رو بسازیم.
توجه کنید که این نسخه طبق قرارداد کد های node اولین پارامتر رو err میزاره و شما باید در کد های پروداکشن این بخش رو حتما هندل کنید.

import { promisify } from "node:util";

// CPS to Promise
function myJobSync(done) {
  return done(null, "this is a result");
}

const myJob = promisify(myJobSync);
console.log(await myJob());

و حالا اینجا ما یک فانکشن CPS style داریم که اومدیم اون رو با استفاده از promisify تبدیل کردیم و بعد نتیجه رو await کردیم و خب همه چی درست کار میکنه.

نکته خیلی خیلی مهم :‌ هر فانکشنی که Callback میگیره لزوما Async نیست دوستان. یعنی myJobSync درسته داره callback میگیره ولی عملیات داخلش به صورت sync هست و یعنی ما اگر از direct style استفاده کنیم منطقی تره ولی خب اینجا برا آموزش بود. برای async کردن کلا یک فرایند دیگ طی میشه که بعدا درمورد event loop که خواستیم صحبت کنیم حتما میگیم.

شما حتی میتونید کتاب خونه های استاندارد هم با این کار تبدیل کنید و استفاده اصلی این دوتا دقیقا اونجا هست

import { randomBytes } from "node:crypto";
import { promisify } from "node:util";

const _randomByte = promisify(randomBytes);
console.log(await _randomByte(5));

به عنوان مثال کتاب خونه node:crypto اکثرا api ها از حالت CPS style استفاده میکنن و خیلی نیاز میشه که اون ها رو بخوایم تبدیل کنیم به Promise که بتونیم await کنیم. و شما الان با این تکنیک راحت میتونید این کار انجام بدید.

در پست بعدی یک مثال خیلی کاربردی با هم میبریم جلو که میتونید داخل پروژه هاتون استفاده کنید و تمرین خوبی هم حتی هست برای عمیق تر شدن در NodeJS

آیا این فانکشن async هست یا خیر.

function myJob(done){
    retrun done(null, "result");
}

مدتی هست از Bun به عنوان package manager دارم استفاده میکنم روی پروژه ها.
به صورت کلی سرعت خیلی خوبی داره ولی چندین بار به یکسری مشکلات خوردم که واقعا اذیتم کردن.

یه تایم دیگ درمورد مشکلات با جزیات بیشتری پست میزارم ولی اگر قصد دارید برای پروژه جدی ازش استفاده کنید پیشنهاد من همون yarn و npm هست در حال حاظر.

معمولا وقتی در حال پیاده سازی Password Auth در Backend برا خودمون هستیم برای امنیت که در صورت leak شدن database پسورد ها رو به صورت Hash ذخیره میکنیم. ۳ الگوریتم پر استفاده برای hash کردن پسورد ها وجود داره به نام های Bcrypt , Scrypt و Argon2 که مرسوم ترین این الگوریتم ها در Nodejs الگوریتم bcrypt هست. در این پست به جزیات تفاوت این الگوریتم ها کاری نداریم که کدوم بهتر از دیگری هست.
نکته ای که اینجا هست این هست که Nodejs اکثر پیاده سازی های bcrypt در nodejs با JS هست که خب صدرصد کند تر از کد CPP هست.
در کتاب خانه node:crypto پیاده سازی native برای scrypt وجود داره که میتونید راحت ازش استفاده کنید. و چون با CPP پیاده سازی شده قطعا performance بهتری داره.
البته اینجا بحث امنیت رو نظر نمیگیرم و فقط راجع به performace داریم صحبت میکنیم و ممکنه با توجه به شرایط امنیتی مختلف شما مجبور باشید که از یکی از اینا اجبارا استفاده کنید.

import { scryptSync } from "node:crypto";

const myPassword = "RawP@sword";
const mySalt = "salt";
const hashedPassword = scryptSync(myPassword, mySalt, 64);
console.log(hashedPassword);

در پایه ای ترین حالت از شما پسورد خام و یک salt رو میگیره و با توجه به ترکیب اینها یک Buffer به شما میده که حالا میتونید با فرمت های مختلف مثل hex یا base64 سریالایز و ذخیره کنید.
پارامتر سوم هم keylen هست که حداقل مقدار طبق best practise ها 64 byte هست که هرچقد بالاتر باشه درصد کرک کردن پسورد سخت تره
(سعی کنید بیشتر از 512 نزارید چون برای generate و validate کردن هزینه زیادی رو سرور داره).

و این که در این مثال از نسخه Sync استفاده شده و شما حتما باید از async api برای کد پروداکشن استفاده کنید.
نکته بعد این که فقط به صورت CPS async style ارایه شده و حتما باید از promisify استفاده کنید در صورتی که نیاز به Promise دارد.
در پست بعدی راجع به best practise های استفاده از این توضیح خواهم داد ولی یک سوال دارم از شما و یک چلنج.
۱. دلیل استفاده از salt چی هست؟ اصلا salt چی هست؟ (کامنت بزارید زیر پست)

و اما چلنج :‌ معمولا کتاب خونه های ارایه شده برای پسورد خودشون عملیات serialize کردن و validation رو انجام میدن.
اما اینجا تمام این کارا رو باید خودتون دستی انجام بدید و فقط از این api براای secure کردن پسورد استفاده کنید.
میخوام بگم که سعی کنید خودتون یک hashing password class به همراه validator پیاده سازی کنید چلنج های باحالی داره این کار و خیلی چیزا یاد میگیرید.

همونطور که اکثریت این رو درست گفتن پس فکر کنم نیازی به توضیح نداره.

دوتا از پرکاربرد ترین و مهم ترین event های در NodeJS که خیلی کم توجهی بهش شده "uncaughtException" و "unhandledRejection " میباشد که پیشنهاد میکنم اگر برنامه ای روی production دارید حتما این دو رو اضاف کنید.
بخاطر ذات dynamic type و duck type بودن JS و این که شما تا زمان Runtime خبر نداری که یک object چی داخلش هست و Null pointer خیلی مرسوم هست داخل JS و البته ذات async NodeJS تمام این نکات دست به دست هم داده تا یک مشکل خیلی جدی داشته باشیم برای هندل کردن Error هایی که کمتر به چشم میاد و در نظر نمیگیرم.
یعنی ممکنه یک جایی از برنامه احتمال وجود خطایی باشه که اتفاق میافته هیچ لاجیک برای catch کردن نداره و process کرش میکنه و سرویس شما down میشه. صحبت بسته بزارید با کد روشن تر کنم قضیه رو براتون.

async function jobLogicAsync(input) {
  // Some work
  return JSON.parse(input);
}

async function main() {
  // Invalid input at runtime
  const result = await jobLogicAsync("{");
}
main();

اینجا همه چی درست کار میکنه و هیچ مشکلی نیست و یکی از نقد های js این هست که همچین ارور هایی به راحتی به چشم نمیاد. فرض کنید یک
فانکشن داریم یک کاری انجام میده به صورت async با نام jobLogicAsync. همینطور که میبینید هیچ logic ارور هندلینگ وجود نداره و این ارور در بهترین حالت
برنامه ما رو باید crash کنه ( توجه کنید در بهترین حالت این کار باید کنه ) درصورتی که ممکنه یک سری side effect های خطرناک مثل ایجاد corrupt data بشه و
زیان زیادی رو وارد کنه.
تو این مثال هم همه چی درست کار میکنه اگر ما json string درست باشه اما خب کسی خبر نداره از runtime که!
در این شرایط باید راهی پیدا بشه که ما خبر دار بشیم همچین اروری رخ داده به صورت log که بعد trace کنیم و مشکل رو پیدا کنیم. اینجاس که اون دو event به داد ما میرسن.

process.on("unhandledRejection", (err, orgin) => {
  console.error("error : ", err);
  console.log("origin : ", orgin);
  process.exit(1);
});

process.on("uncaughtException", (err, origin) => {
  console.error("error : ", err);
  console.log("origin : ", orgin);
  process.exit(1);
});

این دو event بر روی process global object رخ میدن. و باید روی process.on ما اینا رو دریافت کنیم و در هنگام اجرا پروژه قبل از هرچیزی اینا رو listen کنیم.
کار این دو event به این صورت هست.
1. uncaughtException گرفتن ارور هایی که از sync routine ها هستن
2. unhandledRejection گفرتن promise هایی که reject شدن که .catch نداشتن

به دلیل این که ممکنه هر هرکجایی از یک سیستم چند هزار خطی این ارور ها اتفاق بیوفته شرایط هندل کردن این ارور ها یکم سخت هست به خاطر همین best practise این هست که در صورت اتفاق افتادن این ارور ها اون ها رو لاگ کنیم
و process رو با کد غیر 1 ببندیم و developer رو خبر دار کنیم که مشکل غیر منتظره ای در حالت خاصی رخ داده برسی کن.
میتونید process رو kill نکنید ولی خطر side effect ها رو در پروژه های بزرگ جدی بگیرید.

خیلی میتونیم رو این موضوع عمیق تر بشیم ولی خب فعلا در همین حد بنظرم کافی هست تا زیاد طولانی نشه و یک روزی در ویدیو بیشتر این موضوع رو توضیح میدیم.
البته توضیح خیلی میتونه علمی تر و دقیق تر در سطح node engine باشه ولی خب بنظرم همینقدر برای شروع کافیه.

با سلام و ارادت. شما اگر در پروژه های خودتون از ES Module استفاده میکنید یکی از ضعف های این سیستم این بود که توانایی import کردن فایل های json رو نداشتین.
در حال حاظر به صورت Exprimental این قابلیت روی NodeJS وجود داره و میتونید مستقیم فایل json رو import کنید بدون استفاده از readfile.
نکته مثبت این داستان این هست که شما type safety هم با استفاده از این روش خواهید داشت زیرا این عملیات در یجورایی انگار در compile time رخ میده.
موضوع دیگه این که اگر در پروژه ها خودتون از CommonJs استفاده میکنید سعی کنید از امروز به بعد پروژه ها خودتون رو منتقل کنید روی ESM.
توضیع این که چرا باید از ESM استفاده کنید در این پست واقعا نمیشه و باید به صورت مفصل در ویدیو صحبت کنیم.
برای import کردن json در ESM شما باید از Import Assertions استفاده کنید که خیلی پیچیده نیست و به صورت زیر میباشد.

import fooData from './foo.json' assert { type: 'json' };

const { default: barData } =
  await import('./bar.json', { assert: { type: 'json' } });

باتوجه به ساده بودن کد فکر نکنم نیازی به توضیح بیشتر باشه. و داخل داکیومنت هم مثال ها کامل و ساده هستن میتونید چک کنید.

اگر از typenoscript در پروژه خودتون استفاده میکنید احتمالا تا به حال از ts-node استفاده کردین.
این پکیج گاهی اوقات خیلی عذاب آور هست و نیاز به کانفیگ های زیادی برای بعضی چیزا داره.
مدتی هست داخل بعضی از پروژه هام از tsx استفاده میکنم که این پکیج خیلی راحت تر هست.
بنظرم یه تست بزنید.
https://www.npmjs.com/package/tsx

یکی از موضوعاتی که واقعا جای خالیش در nodejs std حس میشه. پیاده سازی http3 هست.
امروز داشتم گشت گذار میزدم و این library رو پیدا کردم.
این لایبرری رو بیشتر برسی میکنم.
https://github.com/unjs/h3

یکی از دوستان پیشنهاد داد که راجع به clustering در NodeJS صحبت کنیم.
در اینجا یک مقدمه عمیق میگیم چون که این مبحث بحث گسترده ای هست نیاز داره در ویدیو یا یک مجموعه بلاگ پست مفصل درموردش صحبت کنیم.
اولین موضوع درمورد cluster این هست که این یک std lib هست در nodejs و شما با استفاده از این lib میتونید کاری کنید که پروژه شما بتونه درخواست های بیشتری جواب بده. البته چندین نکته در این مورد وجود داره که حتما باید در نظر بگیرید.
- کتابخانه cluster از multiprocessing پشت پرده استفاده میکنه که خود این موضوع یک سری داستان ها داره مفصل باید درموردش صحبت کرد
- از معماری master-slave استفاده شده که این معماری رو ما خیلی میبینم.
- نکته خیلی مهم این که اگر در محیط cloud برنامه شما هست یعنی با استفاده از docker پروژه رو اجرا میکنید به best practise این هست که به هیچ عنوان از pm2 و cluster استفاده نکنید چون که ماهیت کلی تکنولوژی های cloud مثل k8s و docker رو زیر سوال میبره.
در کل cluster lib یک تکنیک برای scale up کردن پروژه به صورت vertical بر روی vps ها یا سرور های بزرگ bare metal هست و باتوجه به این که این روزا با اومده PaaS ها و دلیل سومی که گفتم استفاده از این ماژول کمرنگ شده.
مسلط بودن به cluster lib یکی از skill هایی هست که کلا مجبور میکنه شما رو یک خورده با ساختار سیستم عامل و کامپیوتر ها بیشتر آشنا بشید و ممکنه حتی در مصاحبه ها نقطه قوت شما حساب بشه چون که این روزا استفاده از cloud خیلی رایج هست و dev ها کمتر سمت استفاده از این تکنیک ها میرن.
یک alternative برای cluster که دقیقا همین کار رو انجام میده ولی خیلی راحت تر کرده pm2 هست. اگر پروژه پروداکشن دارید از pm2 استفاده کنید و از خود cluster lib برای پروژه های بزرگ خودتون اگر تجربه زیادی ندارید استفاده نکنید ولی cluster lib یکی از کتاب خونه های خیلی خوب نه تنها در NodeJs بلکه در چندین زبان دیگ که کار کردم هست.
چرا اینطور؟ چون که به نظرم شروع خوبی برای آشنایی با معماری master-slave و IPC و multiprocessing هست. اگر با این مفاهیم آشنا نیستید نگران نباشید. اینجا هدفمون یادگیری عمیق همین موضوعات هست.
این مقدمه ای کلی و کوتاه بود درمورد cluster lib در NodeJs. و در پست های بعد سعی میکنیم با مثال عمیق تر بشیم.

گاهی اوقات پیش میاد در حال دیباگ کردن هستین و console debug انجام میدین.
به عنوان مثال یک object پیچیده رو لاگ میگیرید ولی همچین چیزی رو میبینید.

console.log(compleObject);
// result : [object Object]  

یا با یک nested object طرف هستید و نیاز دارید یک property داخل nested obj ببینید ولی نمیخواید از dot notation استفاده کنید.

// You don't want to do this.
console.log(obj.nested.inner)

در اینجا nodejs یک فانکشن کمکی داره که بهتون کمک میکنه این کار رو انجام بدین

import { inspect } from "node:util"
console.log(inspect(complexObj))

این فانکشن پارمتر های زیادی قبول میکنه و با توجه به نیازتون در دیباگ میتونید کانفیگ انجام بدین.
البته پیشنهاد اول اینه که از دیباگر خود IDE استفاده کنید برای دیباگ. کلا دونستن کار کردن با debugger خیلی بهتون میتونه کمک کنه.
اما گاهی پیش میاد که حالا به دلیل تنبلی یا راحت تر بودن از console debug استفاده کنیم و عادیه.
نکته دیگ این که معمولا چون کار کردن debugger ها با typenoscript نیاز به کانفیگ داره خیلیا سمتش نمیرن ولی خب اگر بدونید خیلی میتونه بهتون کمک کنه.(البته خودم هم در حال یادگیری این موضوع هستم)
موضوع دیگه این که داخل bun و deno این مشکلات حل شده چون داخل خودشون transpiler دارن. احتمالا در آینده شاهد راه آسون تری برای debug کردن پروژه های typenoscript بیاد البته همین الان tsx فکر کنم کمی این قضیه رو روی NodeJs راحت تر بکنه.