گاهی اوقات پیش میاد در حال دیباگ کردن هستین و 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

خیلی از دوستان از nodemon استفاده میکنن برای development تا وقتی تغییری در کد ایجاد میکنن سرور متوجه میشه و ری استرات میشه تا آخرین تغییرات رو داشته باشید.
از ورژن های 16.19.0 و 18.11.0 یک flag به صورت experimental اضافه شده که این کار رو براتون انجام میده بدون استفاده از Nodemon.

node --watch main.js

یکجورایی تقریبا دیگ شاهد Deprecate شدن Nodemon در آینده احتملا خواهیم بود.
#Tip

سلام رفقا ارادت. از این به بعد آپدیت های جالب خبرنامه #AwesomeNodeWeekly رو با این هشتگ خواهیم داشت.

- دوستانی که از Node 16 در حال استفاده روی پروداکشن هستن توجه کنید که بزودی این نسخه به آخر عمر خودش نزدیک میشه و به فکر آپدیت کردن به نسخه LTS جدید باشید.
نسخه Node 16 در تاریخ September 11, 2023 به پایان عمر خودش میرسه.

- کتاب خانه محبوب Mongoose نسخه 8 منتشر شد و بزودی آپدیت های مهم این کتاب خونه رو نگاهی خواهیم انداخت.

#AwesomeNodeWeekly
#NodeUpdate

یکی از نکاتی که خیلی از دوستان میبینیم انجام میدن استفاده از body parser در پروژه های express هست.
نکته ای که وجود داره express از در ورژن 4.16 و 4.17 به صورت پیشفرض middleware های این پکیج رو داخل خودش داره و نیازی نیست body-parser رو اصلا نصب کنید!
یعنی کد زیر رو

import express from "express"
import bodyParser from "body-parser"

const app = express()
app.use(bodyParser.json())

میتونید راحت تبدیل کنید به این کد

import express from "express";

const app = express();
app.use(express.json());

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

لیست middleware هایی که در express به صورت پیش فرض برای گرفتن دیتا وجود دارد.

- express.json 4.16
- express.raw 4.17
- express.text 4.17
- express.urlencoded 4.16
#Express
#Tip

در ادامه مبحث Cluster Module و IPC یکی از مرسوم ترین روش های IPC استفاده از Signal برای فرستادن یک سری پیام های خاص به یک Process هست. به عنوان مثال از معروف ترین Singal ها که همیشه استفاده میکنید و ممکن هست بهشون توجه نکرده باشید SIGINT و SIGKILL میباشد.
ولی سوال اینجاس این Signal ها رو چطور ما استفاده میکنیم بدون این که متوجه بشیم؟
شما وقتی یک برنامه NodeJS یا هر Process دیگه ای داشته باشید وقتی در Terminal کلید Ctrl + C رو میزنید تا برنامه رو ببنید از Terminal ما که یکجورایی Parent Process ما هست یک سیگنال SIGINT به Node Process که Child process ما هست ارسال میشه.
یک روش دیگه برای ارسال SIGINT فرستادن signal از طریق kill هست.

kill -2 <PID>

حالا بریم با یک مثال توضیحات بیشتری رو بدیم

// main.js

console.log("PID : ", process.pid);

process.on("SIGINT", (s) => {
//clean up code
  console.log("sigint\n");
  process.exit(0);
});

setInterval(() => {}, 1000);

نکته اینجاس که ما میتونیم روی برنامه های خودمون یک سری listener داشته باشیم که به این سیگنال ها گوش میکنند که روی process object ما میتونیم این ها رو register کنیم.
حالا بزارید اینجا خود signal های SIGINT و SIGKILL رو بیشتر توضیح بدم
- سیگنال SIGINT به Process میگه قرار بسته بشی و اگر نیاز داره جایی تمیز کاری انجام بدی مثل بستن کانکشن به دیتابیس بستن file denoscriptor ها لاگ کردن یکسری چیزها این کارا رو انجام بده و بعد خودمون باید با process.exit خارج بشیم. نکته این هست که ما میتونیم به این سیگنال گوش نکنیم و نادیده بگیریم یعنی اگر ما خط process.exit رو نداشته باشیم process همچنان به عمر خودش ادامه میده. یک سیگنال دیگ که خیلی شبیه به SIGINT هست SIGTERM نام داره که میتونید خودتون برید چک کنید کنجکاوی جالبی میتونه براتون باشه.
- سیگنال SIGKILL سیگنالی هست که شما به هیچ عنوان نمیتونید capture کنید و یجورایی سیستم عامل process شما رو خفه میکنه بدون این که بهش خبر بده. سیستم عامل با این سیگنال میگه برای من مهم نیست که تو clean up کردی یا نه من میخوام تو رو بکشم!
به عنوان مثال در این برنامه خط process.exit رو حذف کنید و با ctrl+c چنتا SIGINT بفرستید. بعد برای کشتن process به صورت کلی از دستور زیر برای فرستادن SIGKILL استفاده کنید و Process رو خفه کنید.

kill -9 <PID>

در معماری master-slave در cluster module از این سیگنال ها استفاده هایی میشه و اینجا ما مقدمه ای کلی راجع به این سیگنال ها داشتیم که کلا چی هستن. در ادامه سعی میکنیم با مثال روی cluster module با این سیگنال ها بازی کنیم. و یکم بیشتر باهاشون آشنا بشیم.

این تکه کد از ریپو اصلی NestJS هست.
https://github.com/nestjs/nest/blob/master/packages/core/package.json
نکته ای که وجود داره peerDependencies هست.
کلا peerDependencies کمتر راجع بهشون صحبت شده و نکته اینجاس که ممکن هست ندونستن این ویژگی ریز باعث بشه هفته ها دنبال باگی بگردید که اصلا وجود نداره.
این باگ ترسناک باعث تغییر رفتار instanceof میشه! و مخصوصا در پروژه های NestJS بخاطر استفاده سنگین از peerDependencies ها هرلحظه در کمین نشسته.
و این که replicate کردن این باگ و برسی این موضوع چون به ساختار Memory و load شدن class ها در حافظه خیلی ربط داره و دید جالبی از حافظه به شما میده.
در ادامه به صورت خیلی کلی و خلاصه راجع به کلیت peerDependencies صحبت میکنیم. ولی در آینده حتما یکی از موضوعاتی هست که درموردش عمیق صحبت خواهیم کرد.
صرفا هدف از این پست ایجاد کنجکاوی برای شما و مطالعه درمورد این موضوع در صورت علاقه.

#Tip

به صورت کلی Stream ها در NodeJS خیلی کمتر شناخته شده هستند هرچند بخش اساسی و فلسفه Node رو تشکیل دادن. باز هم با این وجود بخش هایی از Stream و Event ها در NodeJS باز کمتر از بقیه شناخته شده اند.
یکی از این موضوعات ویژگی استفاده از event ها به صورت promise api و listen کردن روی stream ها و event ها.
بزارید با مثال این موضوع رو بیشتر باز کنم.

import { EventEmitter } from "node:events";

// PART 1
const emitter = new EventEmitter();

// PART 2
process.nextTick(() => {
  emitter.emit("message", 543);
  emitter.emit("message", "Hello NodeMaster");
});

// PART 3
emitter.on("message", (data) => {
  console.log("from event:", data);
});

قسمت اول مشخص هست و نیازی به توضیح نداره در قسمت دوم به صورت async روی "message" یک string و یک number ارسال میکنیم تا در پارت سوم با استفاده از متد on روی emitter ایجاد شده در پارت اول listen کنیم و دیتا رو بفرستیم روی stdout.
این استایل کد خیلی مرسوم هست در NodeJS و همه با اون آشنایی داریم. ولی اگر همین رو بخوایم ریفکتور کنیم به شکلی که کمتر میبینیم چطور میشه؟

import { EventEmitter, on } from "node:events";

// PART 1
const emitter = new EventEmitter();

// PART 2
process.nextTick(() => {
  emitter.emit("message", 543);
  emitter.emit("message", "Hello NodeMaster");
});

// PART 3
for await (const [data] of on(emitter, "message")) {
  console.log("from event:", data);
}

تمام قسمت های کد به همون شکل قبل هست به جز پارت ۳ و یک import جدید با نام on که در ادامه توضیح خواهیم داد.
در کتابخانه "node:events" چندین دوتا فانکشن وجود داره به اسم on و once که معادل متد های on و once روی evetemitter ها هست ولی خب متفاوت عمل میکنند. بزارید اینطور بگم هدف ها یکی هست ولی روش انجام کار متفاوت هست و این موضوع بخاطر این هست که در هرکدوم یک سری کارا رو میشه راحت تر انجام داد و البته این موضوع خارج از این بحث میباشد.
در ساده ترین حالت ممکن این فانکشن یک object از event emitter و نام رویدادی که قراره listen بشه رو دریافت میکنه ( همینطور که میدونید stream ها هم event emitter هستند)
و یک AsyncIterator به شما برمیگردونه.
حالا این که AsyncIterator چیست و چرا خودش یک مبحث با کلی توضیحات هست و اینجا وارد این موضوع نخواهیم شد و در همین که بدونیم با استفاده از AsyncIterator میتونیم همچین کار هایی رو انجام بدیم کافی هست.
#Tip

خیلی خیلش تشکر میکنم از شما دوستان که به بنده افتخار دادین و ۲۰۰ نفر شد چنل 🎉
و این که یک خواهش از شما دوستان داشتم.
اگر مطالب کانال براتون مفیده من داخل لینکدین هم اینها رو به اشتراک میزارم. واقعا ممنون میشم اگر اونجا لایک و repost کنید. دوباره ازتون تشکر میکنم واقعا باورم نمیشه ۲۰۰ نفر شدیم 🎉
https://www.linkedin.com/feed/update/urn:li:activity:7137731168061333504/