مدتی هست از 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 راحت تر بکنه.

بزارید ادامه این بحث رو با توضیح کوتاهی از Process شروع کنیم.
Process چیست؟
در حقیقت Process یک instace از یک برنامه در حال اجرا که معمولا روی RAM جا دارد. برنامه در حال اجرا روی سیستم عامل برای اجرا دستورات خود نیاز به منابعی از قبیل حافظه و cpu time دارد.
وظیفه سیستم عامل این هست که این منابع را برای Process ها تامین کند. ( این که چطور برنامه وارد فرایند اجرا میشه رو اینجا کاری نداریم و یک تایم دیگ راجع بهش صحبت میکنیم‌ )

سیستم عامل برای هر Process یک ID در نظر میگیره که بهش میگیم PID و هر Process هم حداقل یک Thread داره. سیستم عامل برای هر Process یک فضای مجزا در RAM مشخص میکنه و میگه فقط و فقط تو حق داری در این فضا اطلاعاتت رو ذخیره کنی و
هیچ Process دیگه ای حق نداره داخل این قسمت از حافظه چیزی ذخیره کنه و اگر یک Process شیطون بخواد این کار رو انجام بده سیستم عامل میگه داداش تو اجازه نداری.

console.log(process.pid)

اگر این کد رو اجرا کنید هربار یک pid جدید به شما میده چون هر pid برای هر process تا زمانی که اون process زنده هست برا خودشه.

نکته جالب اینجاس که اگر یک Process بخواد با Process های دیگ صحبت کنه یک کاری باهم انجام بدن یک سری روش ها برای انجام این کار وجود داره به اسم IPC (InterProcess Communication) . وارد این مبحث نمیشیم چون خیلی پیچیده هست و خارج از بحث ما هست.
اگر بخوایم یک مثال جالب بزنیم در حقیقت کل اینترنت مجموعه ای از Process ها هستن که در از طریق IPC صحبت میکنن با هم دیگه.
حالا میشه از توضیحات بالا استفاده کرد و پروژه های خودمون رو Scale کنیم با استفاده از Cluster Module. به صورت فرمال دو نوع IPC method هست.
- IPC روی یک ماشین
- IPC بین ماشین های مختلف ( همون مثال بالا )
و نکته اینجاس که Cluster Module از طریق نوع اول پروژه شما رو Scale میکنه و مزایا و معایب خودش رو داره.
به این نکته هم توجه کنید که چون هر کدام Process مجزا هستن به فضای حافظه یک دیگر دسترسی ندارند و تنها راه ارتباط استفاده از IPC Methods هست. ( البته یکی از متد های IPC که فک کنم سریعترینشون هم هست Shared memory هست که ما اینجا فعلا در نظر نمیگیرم چون میخوایم خیلی پایه ای صحبت کنیم )

دوستان این موضوع رو من خیلی خلاصه کردم و یک دنیایی هست. بخاطر همین خلاصه نویسی خیلی از نکات رو در نظر نگرفتیم ولی خب بنظرم در همین حد کافی هست. یک تایم دیگ خیلی مفصل تر راجع به مبحث Process صحبت میکنیم ولی فعلا چون هدف Cluster Module هست در همین حد کافیه.
و در ادامه با مثال ها جزیات بیشتری رو برسی میکنیم.

#چالش
برا دوستانی که دوست دارن کنجکاوی کنند یک سوال دارم.
سوال :‌ Zombie Process 🧟 چیست و چطور ایجاد میشود.

https://nodedownloads.nodeland.dev/
این وب سایت میزان دانلود نسخه های NodeJS رو نشون میده.
باحاله!😄

یک ابزار خوب دیگه که میتونه در کد بیس هایی که دارید خیلی کمکتون کنه knip هست.
https://knip.dev/
این ابزار کارش این هست که dead code ها رو پیدا کنه و بهتون گزارش بده که از شرشون خلاص بشید.
#NodeWeekly

از این به بعد با #NodeWeekly ابزار هایی که در خبرنامه های مربوط به Node منتشر میشه گلچین میکنم و براتون میزارم

چند روزی هست که Node 20.10 LTS منتشر شده یکی دوتا تغییر جالب داشته که برسی میکنیم این تغییرات رو باهم.

یکی از نکات جالب اضافه شدن Web Api مربوط به WebSocket کلاینت.

const wsClient = new WebSocket("ws://websocketServer:7000")

اگر این رو با node ران کنید به ارور میخورید و میگه WebSocket وجود نداره.
اما اگر با فلگ --experimental-websocket اجرا کنید WebSocket به global object اضافه میشه.

node --experimental-websocket main.js

#NodeUpdate
#20_10

فلگ جدید که اضافه شده میتونید default module system رو عوض کنید. قبل از این داستان باید داخل package.json مقدار type رو روی module بزارید تا بتونید پروژه خودتون رو با ESM اجرا کنید ولی با این فلگ دیگه نیازی به این کار نیست.

// main.js
import crypto from "node:crypto"

شما اگر این رو اجرا کنید بدوت اضافه کرد type: module در package.json یا بدون .mjs به عنوان فرمت به ارور میخورید چون در حال حاظر CommonJS در Node پیش فرض هست.
حالا برای عوض کردن این پیشفرض میتونید این کار کنید.

node --experimental-default-type module main.js

#NodeUpdate

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

درمورد thread pool pattern که سرچ کردم به یه سورس گیت رسیدم که میاد یه  pool از worker ها ایجاد میکنه و باید فقط تسک ها رو مدیریت کرد. و لینک ش رو میذارم اگه کسی بهش نیاز پیدا کرد یا خواست سورسش رو بررسی کنه:

https://github.com/josdejong/workerpool

سخت ترین کتاب برنامه نویسی اولین کتاب برنامه نویسیه!

یک flag دیگه که اصلا دیگه حتی نیازی به این کار هم نیست و در نسخه 20.10 اضافه شده.

node --experimental-detect-module main.js

خودش تشخیص میده که آیا از سینتکس ES Module در پروژه شما استفاده شده یا خیر.
و اگر استفاده شده باشه همه چی out of the box کار میکنه
#NodeUpdate