خب ظاهرا در جهت ورژن جدید Express 5 حرکت های جدی داره صورت میگره که میتونید در این github issue اون رو پیگیری کنید.
https://github.com/expressjs/discussions/issues/233

#NodeJS

یکی دیگ از API های جالبه 'node:perf_hooks' استفاده از measure فانکشن هست که به ما در نهایت یک PerformanceMeasure obj برمیگردونه. این پست خیلی به پست قبل مرتبط هست پس حتما اول اون رو بخونید.
https://news.1rj.ru/str/NodeMaster/206
به مثال پست قبل اگر دقت کنید ما با استفاده از mark یک سری مارک مشخص میکنیم تا اون لحظه رو به صورت دقیق ثبت کنیم. حالا اگر بخوایم در دقیق ترین حالت ممکن duration رو اندازه گیری کنیم اینجا measure به کمک ما میاد.

import { performance } from "perf_hooks";
import { setTimeout } from "timers/promises";

function myLogic() {
  // Complex logic
  return setTimeout(3000, "Hello NodeMaster");
}
const perf1 = performance.mark("start_perf_check");
await myLogic();
const perf2 = performance.mark("end_perf_check");

const mes = performance.measure(
  "logicDuration",
  "start_perf_check",
  "end_perf_check"
);
console.log(mes);

در اینجا ما به عنوان arg اول یک نام برای measure مشخص میکنیم و در نهایت اسم startMark و endMark رو بهش پاس میدیم و نتیجه به صورت زیر میگیریم.

PerformanceMeasure {
  name: 'logicDuration',
  entryType: 'measure',
  startTime: 21.1939,
  duration: 3004.3700479999998
}

کلاس PerformanceMeasure مثل PerformanceMark پست قبل یک subclass از performanceEntry هست و entryType در این حالت همیشه measure هست.
حالت های دیگ استفاده از این فانکشن بدون endMark هست که در این حالت خود فانکشن مثل endMark عمل میکنه و در صورتی که هیچ mark در نظر نگیریم startTime با مقدار 0 هست و duration لحظه ای رو نشون میده که از شروع برنامه گذشته تا به اون measure رسیده.

#Tip #NodeJS

چند وقت پیش یک همچین پستی گذاشته بودم که در هنگام تست نوشتن با همچین کدی روبرو شده بودم

3 === new Number(3)

جواب این false میشه و یکم برام عجیب بود دوستان هم توضیحات خوبی دادن منطقی و درست بود ولی کامل جوابم رو نگرفتم که چرا اینطوره.
شما اگر قصد دارید با استفاده از function هایی مثل String, Boolean, Number عملیات type conversion انجام بدید اگر از new استفاده کنید در حقیقت typeof برابر با object میشه و کاملا منطقی هست به این دلیل که باهاش مثل constructor function رفتار میشه. حالا object که از این حالت بدست میاد شبیهه به primitive ها رفتار میکنه ولی در همچین سناریویی تفاوت خودش رو نشون میده. دلیل این رفتار هم بخاطر موضوعات تاریخی مربوط به #JavaScript هست و این موضوع هم درنظر داشته باشید که در code base های بروز اصلا منطقی نیست از این موضوع استفاده کنید و کاملا از این موضوع فرار کنید. فقط گاهی ممکن هست بهش بر بخورید پس دونستن این موضوع میتونه بهتون کمک کنه

#Tip

سلام و ارادت دوستان.
این پست تبلیغ نیست.
یکی از دوستان من مدتی هست داره فعالیت میکنه و کلی ویدیو آموزشی یوتیوب گذاشته و الان دوره #NestJS ایشون کامل هست.

و این که یکسری مجموعه وبینار هم برگزار میکنه و در حال حاظر درحال برسی Design pattern ها هستن.

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

https://news.1rj.ru/str/mostafaeffatiofficial

هرچقدر از زیبایی این بگم کم گفتم.
#Clang
https://youtu.be/tas0O586t80?feature=shared

اگر در پروژه خودتون CI/CD دارید برای نصب dependency های پروژه #NodeJS خودتون اگر از #NPM استفاده میکنید یادتون باشه که از ci استفاده کنید

npm ci

هدف از استفاده این command برای استفاده در محیط هایی مثل CI میباشد یا در حالتی که میخواید یه نصب تمیز داشته باشید روی محیطی که دارید اجرا میکنید برنامتون رو.

تفاوت هایی که این روش با npm install داره چیه ؟
- حتما و حتما باید package-lock.json داخل پروژه شما باشه.
- اگر package-lock.json نبود با در حقیقت نصب ما ادامه پیدا نمیکنه و package-lock.json جدید آپدیت ایجاد نخواهد شد.
- اگر node_modules وجود داشته باشه ( در سناریو هایی که فراموش میشه به عنوان مثال در .gitignore بزاریم ) قبل از نصب حذف میشه و یک node_modules جدید ایجاد میشود.
- هیچ وقت package.json آپدیت نمیکنه و دقیقا همون چیزی هست که ما موقع ci میخوایم.

معادل این روش رو تقریبا میتونید روی pnpm هم به این شکل داشته باشید.

pnpm install --frozen-lockfile

و معادل این روش در Yarn

yarn install --frozen-lockfile

به صورت کلی اگر در محیط production میخواید پروژه خودتون رو اجرا کنید باید یطوری dep ها رو نصب کنید که از package-lock این عملیات صورت بگیره. هم سریعتر هست و هم تضمین بر این که dep hell نخواهید داشت.

دوستان ofood پوزیشن خالی Nodejs
#Work
https://twitter.com/mh_daneshvar/status/1793312352286232933?t=dVDwvqfRzUWSf64mvIhflA&s=19

برای #NodeJS آپدیت 20.14 LTS منتشر شد. ویژگی جدید خاصی به این آپدیت اضافه نشده و بیشتر باگ فیکس بوده.
https://nodejs.org/en/blog/release/v20.14.0

🔥یک خبر خیلی داغ مربوط به ۲ دقیقه پیش.
سازمان حج و زیارت هک شد.
یعنی کلا اطلاعات شخصی ما ایرانی ها داخل سرویس ها ایرانی open source هست و هردوطرف کارفرما و برنامه نویس صدرصد مقصر این موضوع هستند به نظر من.
https://news.1rj.ru/str/irleaks/24

یکی از ویژگی های جدیدی و کاربردی که در #ES2024 اضافه شده و هم برای بچه های #Frontend و هم #Backend میتونه مفید باشه.
یکی از pattern های معروف برای ایجاد یک async function در #JavaScript به این صورت هست.

function job() {
  return new Promise((resolve, reject) => resolve(2));
}

معمولا از این ویژگی وقتی استفاده میشه که قصد داریم یک wrapper برای یک CPS Style Async Function بنویسیم.
قبلا در مورد این که CPS Style چیست و چرا مفصل صحبت کردیم و میتونید از این لینک مطالعه کنید.
https://news.1rj.ru/str/NodeMaster/19
حالا با این API جدید میتونیم کد بالا به این صورت refactor کنیم

function job() {
  const { promise, reject, resolve } = Promise.withResolvers();
  resolve(2);
  return promise;
}

با استفاده از static method جدیدی که به Promise اضافه شده یعنی Promise.withResolvers میتونیم از شر constructor خلاص بشیم. ( یجورایی میشه گفت factory pattern حساب میشه )
یک موضوع شاید براتون سوال پیش که چرا گفتم از شر constructor خلاص بشیم. آیا مشکلی داره؟ جواب طبق سایر جواب ها برنامه نویسی میتونیم بگیم بستگی داره. ولی من حس میکنم با توجه به تغییراتی که من میبینیم به مفهوم Aggregation در OOP خیلی احترام بیشتری داره گذاشته میشه.

این آپدیت خیلی جدیده و در حال حاظر در #NodeJS ورژن 22 هستش.
البته دوباره این رو باید بگم که #Deno پرچم داری کرده و از ورژن 1.38 این ویژگی رو زودتر اضافه کرده.

#Tip

دیتابیس های Sql مثل postgres و mysql مشکل scale ندارند.
بیشتر skill issue باعث میشه scale نشن.

این بلاگ پست با بلاگ پست گیت هاب که درمورد migrate کردن به mysql ورژن 8 یا 7 بود خیلی با ارزش هست

یوتیوب چطوری از 2.49 میلیارد کاربر با MYSQl پشتیبانی میکنه؟

تو این مقاله میتونید بخونید

https://newsletter.systemdesign.one/p/vitess-mysql

@DevTwitter

اگر تا حالا فکر کردین که چطور فریمورک ها رو برای ما developer های عادی توسعه میدن جواب شما یک magic هست به اسم #Metaprogramming . این کار مثل برنامه نویسی معمولی که ما انجام میدیم تکنیک های مختلف داره که یکی از اونها رو در این پست باهم برسی کردیم.
https://news.1rj.ru/str/NodeMaster/115

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

حالا یکی از این جادو های کاربردی #Metaprogramming این هست که اگر یک Instance از یک Object داریم که یک Parrent Class داره چطور فقط و فقط متوجه بشیم که چه Attr هایی مخصوص به اون Child Class هست و Attr های Parrent رو نادیده بگیریم. و جواب این سوال خیلی سادس :

const myPrototype = { x: 1, y: 2 }; // Parrent
const myObj /* Child */ = Object.create(myPrototype);

myObj.name = "point"; // Instance Prop

console.log(Object.getOwnPropertyNames(myObj)); // [ 'name' ]
console.log(Reflect.ownKeys(myObj)); // [ 'name' ]
console.log("x in myObj :", "x" in myObj);

در #JavaScript با استفاده از Object.getOwnPropertyNames و Reflect.ownKeys(myObj) میتونیم متوجه بشیم که کدام Atter ها مربوط به Instnace ما یعنی myObj هستند. به این خاطر هست که Atter های Parrent یعنی x و y رو کامل نادیده گرفته میشه و فقط در name رو ما به عنوان Attr میبینم که مستقیما روی Child Instance ما تعریف شده و نه روی Parrent. شاید این مثال یکم پیچیده باشه بخاطر ماهیت Object ها در #JavaScript هست. همین رو اگر بخوایم در #Python برسی کنیم شاید یکم قابل درک تر باشه و البته مثال های دیگ هم در #JavaScript میشه زد ولی خب به نظرم بهتره بزاریم برای کنجکاوی خودتون.

class Parrent:
    def __init__(self) -> None:
        self.x = 1
        self.y = 2

class Child(Parrent):
    def __init__(self) -> None:
        super().__init__()
        self.name = "point"


myObj = Child()

parrentAttrs = set(dir(Parrent()))
childAtters = set(dir(Child()))

print(childAtters.difference(parrentAttrs))

یک نکته خیلی جذاب کلا خارج از بحث که به نظرم ارزش توجه کردن داره استفاده از set برای رسیدن به نتیجه ای شبیه به مثال #JavaScript هست. و اینجا به عنوان مثال مستقیم یکی از کاربرد های Set Object و Set theory رو مستقیم و خیلی کوچیک میبینید.
نکته ای که خیلی مهم باید توجه بشه این هست که بین تکنیک استفاده از ownKeys و getOwnPropertyNames تفاوت هایی وجود داره که اگر استقبال بشه عمیق تر وارد این موضوع میشیم.

#Tip

اگر درحال یادگیری #NestJS هستید و یا مدت زیادی هست با این framework محبوب کار میکنید به این نکته حتما توجه کنید.
1. به هیچ عنوان از Nest CLI برای ایجاد یک پروژه جدید استفاده نکنید.
2. حداقل اگر استفاده میکنید سعی کنید dep های اضافه رو پاک کنید.

درمورد نکته اول یک اتفاق فاجعه بار درصورت رعایت نکردن میتونه رخ بده. اگر با Nest CLI پروژه ایجاد کنید و بعد به tsconfig یک نگاهی بندازید همچین خطی رو میبینید.

{ "strictNullChecks": false }

همین یک خط config توانایی این رو داره که پروژه رو تبدیل کنه به میدان مین جنگی و گوشی شما یکهویی ساعت ۱ شب زنگ میخوره کارفرما به شما میگه رو production مشکل داریم و بعد از چک کردن log ها متوجه Null pointer های زیبا خواهید شد.
قبلا درمورد این موضوع یعنی Null References: The Billion Dollar Mistake در این پست مفصل صحبت کردیم.
https://news.1rj.ru/str/NodeMaster/84

این نکته خیلی میتونه ترسناک باشه به این دلیل که اگر کسی تازه داره روی کد onboard میشه اگر معمولا فرض بر این داره که #TypeScript کمک به Null safe بودن داره و نکته جذاب اینجا هست که ترکیب false بودن این flag با همچین تصور پیشفرضی به زیبایی میتونه جهنم باشه ( به قول خارجی ها road to disaster ). چندتا config دیگ هم مربوط به safety به صورت پیش فرض در این حالت false هستن که هیچ کدوم به اندازه این ترسناک نیستن.
در ادامه اگر روی یک code base بزرگ باشید و این flag مهم از قبل false بوده بعد از true کردن این flag پروژه شما در کسری از ثانیه به رنگ خون در میاد و فرایند refactor کردن در این سناریو فرایندی بسیار هزینه بر هست. پس بهتره از همون اول پروژه این رو درنظر بگیرید.

درمورد نکته دوم این که به صورت پیش فرض #NestJS یک سری Dep به پروژه از این روش اضافه میکنه که ممکنه اصلا نیازی بهش نداشته باشید و خب این یک bad practise محسوب میشه ( YAGNI Principle ). این حالت زمان build time هم الکی اضاف میکنه و در پروژه بزرگ میتونه آزار دهنده باشه. موضوع بعد در این مورد این که بعضی از package هایی که وجود دارن در package.json آپدیت نیستن و خیلی سریعتر از زمان معمول ممکنه نیاز به آپدیت کردن پروژه داشته باشید. با نصب کردن dep ها به صورت دستی حداقل از این موضوع میتونید اطمینان پیدا کنید که از جدیدترین ورژن پکیج ها دارید استفاده میکنید.

#Tip #NodeJS

ترسناک تر از Dynamic Type بودن #JavaScript در حقیقت پروژه #TypeScript هست که به تو توهم Type safe بودن بده.
هروقت پروژه #TypeScript دیدین اول بیاین این قسمت رو چک کنید که مثل عکس بالا strict باشه و هیچ کدوم از flag های زیرش false نباشه.
اگر در موقع کار با #TypeScript مجبور شدین اینجا فلگی رو false کنید این برداشت رو میتونید کنید که #TypeScript بلد نیستید!

هم اکنون با این ابزار جدید میتونید #TypeScript رو به #Lua تبدیل کنید.
اگر براتون سوال هست که کجا میتونه کاربرد داشته باشه این میتونه باشه که با #Lua میتونید به عنوان مثال برای #Redis اسکریپت بنویسید و حالا میتونید این کار رو بدون یاد گرفتن #Lua و با نوشتن #TypeScript و گرفتن خروجی #Lua انجام بدید. هرچند من شخصا طرفدار این موضوع نیستم ولی جالبه.

https://typenoscripttolua.github.io/

#NodeWeekly

به این خط ساده و کوچک دقت کنید، توانایی این رو داره هرپروژه #FrontEnd و #BackEnd که با #NodeJS توسعه داده شده رو تبدیل به جهنم کنه.

throw 1;

اگر در #TypeScript براتون سوال پیش اومده که چرا در try catch statement تایپ err نامشخص هست، دقیقا بخاطر این موضوع هست. به این دلیل که هر نوع Object رو میشه throw کرد (این خیلی ترسناکه) و چون #JavaScript مفهومی به اسم Compile Time Error نداره و با توجه به طبیعت Dynamic و البته مفسری که #JavaScript داره منطقی هست که شما وقتی try catch استفاده میکنی type برای error تا زمان runtime مشخص نباشه. با مثال پایین بیشتر به عمق مسئله پی میبرید.

try {
  throw { hoo: "Pop up from stack , NodeMaster" };
} catch (err /* type => unknown */) {
  console.log(err);
}

معمولا بعضیا با استفاده از type cast تایپ error رو تبدیل به Error میکنن مثل کد زیر که این به نوع خودش میتونه یک فاجعه دیگه باشه ( آخه نابغه اگر تایپ مشخص بود که Error هست #TypeScript همون اول خودش Error میزاشت و نیاز به Type Cast نبود دیگه)

try {
  throw { hoo: "Pop up from stack , NodeMaster" };
} catch (err) {
  console.log((err as Error).message);  // WTFFFFFFFFF !!!!
}

خب حالا سناریو های بد رو دیدم چطور جلوگیری کنیم؟ در پروژه های #FontEnd تنها روش خیلی خوبی که وجود داره استفاده از instanceof هست در #NodeJS برای #BackEnd هم میشه از این روش استفاده کرد ولی یک تکنیک دیگه وجود داره که اون بیشتر برای سناریوهای خیلی خاص #NodeJS هم کاربردی هست.

try {
  throw { hoo: "Pop up from stack , NodeMaster" };
} catch (err) {
  if (err instanceof Error) {
    console.error("it's valid error object", err);
  } else {
    console.error("WHAT THE F IS THIS ???", err);
  }
}

برای پروژه های #NodeJS در std مربوط به Node یک فانکشن کمکی هست به اسم isNativeError که همین کار instanceof رو میکنه. حالا سوال پیش میاد که چرا باید از این استفاده کنیم؟ در حالت هایی به عنوان مثال استفاده از "node:vm" و ایجاد یک context جدید میتونه دردسر ساز بشه و instanceof نتونه تشخیص بده Error رو که نتایجش هم مشخصه. نکات دیگه ای هم وجود داره که پیشنهاد میکنم داکیومنت مربوط به این بخش رو بخونید کامل با مثال ساده توضیح داده.

import { types } from "node:util";
try {
  throw { hoo: "Pop up from stack , NodeMaster" };
} catch (err) {
  if (types.isNativeError(err)) {
    console.error("it's valid error object", err);
  } else {
    console.error("WHAT THE F IS THIS ???", err);
  }
}

حالا یک سوال دیگ شاید براتون پیش بیاد که چرا اینقدر بدبینانه به مسئله نگاه میکنیم؟
تو دنیایی که #NPM وجود داره اعتماد به پکیج های 3RD Party گاهی اوقات میتونه گرون تموم بشه. شاید اون پکیج که استفاده میکنید این داستان رو رعایت نکرده باشه. پس بهتره ما دقت کنیم تا از runtime ارور های نصف شب جلوگیری کنیم و با آسوده بخوابیم.

#Work
این تیم دنبال #NodeJS میگرده اگر دوست داشتید رزومه خودتون رو بفرستید.

https://jobvision.ir/jobs/job-detail/770925?ReferrerJobPosition=8&row=3&pageSize=30&keyword=node&searchId=385378404706959333

داشتم طبق عادت stackoverflow میگشتم دنبال نکته جدید برای یادگیری.
به یک سوال خوردم و وقتی روش وقت گذاشتم حس کردم یک باگ روی #NodeJS هست و رفتار منطقی نمیبینیم و خب بقیه هم ظاهرا به همین نکته رسیدن اون سوال باعث ایجاد یک issue روی #NodeJS core شد اگر دوست داشتید نگاهی به سوال بندازید و برسیش کنید خیلی جذاب بود.

سوال:
https://stackoverflow.com/questions/78630248/how-to-properly-abort-node-readline-promise-question

گیت هاب:
https://github.com/nodejs/node/issues/53497

یک Pattern وجود داره که خیلی درموردش صحبت نمیشه در اکوسیستم #JavaScript چه پروژه های #FrontEnd و چه #Backend که با #NodeJS و بقیه runtime ها توسعه داده شده باشن. این پترن خیلی ساده هست. استفاده نکردن ( یا حداقل استفاده ) از Anonymous function ها میباشد.

حالا سوال پیش میاد چرا از این پترن باید استفاده کنیم؟
وقتی دارید برنامه توسعه میدین و به نوعی چه توسط خودتون یا Framework که استفاده میکنید با فرایند IOC درگیر هستید مثل #React یا حتی #Express و ... اگر سایز پروژه بزرگ باشه برای پیدا کردن Bug ها به هیچ عنوان تکنیک console.log راه بهینه ای نیست. و معمولا از ابزار ها و تکنیک های مختلف در کنار هم استفاده میشن تا این فرایند راحت تر باشه. در کنار این مفاهیم لاگ کردن Error ها و stack trace مربوط بهشون خیلی مهم هست و خیلی کمک میکنه تا scope مربوط به به باگ رو کوچک تر کنیم و سریعتر بتونیم باگ رو پیدا کنیم.

با استفاده زیاد از Anonymous function ها که معمولا بیشتر در هنگام arg برای پاس دادن به عنوان callback استفاده میشن، stack trace شکل خوبی نخواهد داشت و اگر زیاد استفاده بشه حتی stack trace میتونه کاملا بی مصرف بشه و با این کار یکی از عناصر خیلی مهم برای debug کردن رو از دست میدیم. به مثال زیر توجه کنید.

function iocContainer(cb) {
    cb()
}
iocContainer(() => { throw new Error("ugly stack trace") })

    at /home/imanhpr/codes/main.js:6:28
    at iocContainer (/home/imanhpr/codes/main.js:2:5)
    at Object.<anonymous> (/home/imanhpr/codes/main.js:6:1)

اینجا سایز پروژه کوچک هست و راحت میشه Error رو پیدا کرد چون جزیات زیادی در stack وجود نداره و کد framework هم در نظر گرفته نشده. اما توجه داشته باشید که اون خط آخر یعنی Object.anonymous در شرایط فشار باگ روی production خیلی میتونه ترسناک باشه.یک نکته که حتی میتونه وحشتناک تر کنه داستان رو پروژه #TypeScript بدون source map و اگر به این ترکیب esbuild هم اضافه بشه جای صحبتی اصلا باقی نمیمونه.

حالا با یک مثال واقعی تر و خیلی ساده این موضوع رو برسی میکنیم

const express = require("express")

const app = express()

app.get("/", (req, res) => {
    throw new Error("ugly error")
})

app.listen(3000)

Error: ugly error
    at /home/imanhpr/codes/main.js:6:11
    at Layer.handle [as handle_request] (/home/imanhpr/codes/node_modules/express/lib/router/layer.js:95:5)
    at next (/home/imanhpr/codes/node_modules/express/lib/router/route.js:149:13)
    at Route.dispatch (/home/imanhpr/codes/node_modules/express/lib/router/route.js:119:3)
    at Layer.handle [as handle_request] (/home/imanhpr/codes/node_modules/express/lib/router/layer.js:95:5)
    at /home/imanhpr/codes/node_modules/express/lib/router/index.js:284:15
    at Function.process_params (/home/imanhpr/codes/node_modules/express/lib/router/index.js:346:12)
    at next (/home/imanhpr/codes/node_modules/express/lib/router/index.js:280:10)
    at expressInit (/home/imanhpr/codes/node_modules/express/lib/middleware/init.js:40:5)
    at Layer.handle [as handle_request] (/home/imanhpr/codes/node_modules/express/lib/router/layer.js:95:5)

این مثال کیلومتر ها با پیچدگی پروژه های production فاصله داره اما همین کد ساده نشون میده چقدر توجه به این نکته میتونه ساعت ها از وقت شما نجات بده و کار کم استرس
تری هم تجربه کنید. مشکل دقیقا خط اول stack trace هست که هیچی ازش وجود نداره ( در این مثال خوش شانسیم که خطی که این اتفاق افتاده دقیقا اشاره داره به همون callback ما ولی همیشه اینطور نیست )

برای داشتن زندگی شیرین تر کافیه کمتر از Anonymous function ها چه به شکل arrow و چه با function keyword استفاده کنید. و برای function ها نام مناسب انتخاب کنید. مثل سناریو پایین که rootHandler رو داریم.

app.get("/", function rootHandler(req, res) {
    throw new Error("ugly error")
})
// OR
const rootHandler = (req, res) => {
    throw new Error("ugly error")

}
app.get("/", rootHandler)

Error: ugly error
    at rootHandler (/home/imanhpr/codes/main.js:6:11)
    at Layer.handle [as handle_request] (/home/imanhpr/codes/node_modules/express/lib/router/layer.js:95:5)

حالا چند نکته باید در نظر بگیرید.
- تفاوت arrow function و function keyword رو بدونید گاهی ممکنه دردسر ساز بشه.
- اگر از #TypeScript استفاده میکنید از اهمیت source map هرگز غافل نشید.

#Tip