یکی دیگ از api های کاربردی node:perf_hooks استفاده از فانکش mark هست. این فانکشن تقریبا کاربردی شبیه به فانکشن .now داره که در پست قبلی مربوط به این موضوع توضیح داده بودم ولی یکم دست ادم رو برای log گرفتن و داشتن metadata های مختلف باز میزاره. به عنوان مثال به این کد دقت کنید.

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");

console.log(perf1);
console.log(perf2);

به عنوان مثال یک فانکشن داریم که داره یک کار خیلی پیچیده انجام میده و این فانکش زمان بر هست استفاد از .now ممکنه جالب نباشه چون در code base های بزرگ trace کردن یکم چالش میشه. این api ها یجورایی پشت پرده ابزار هایی مثل elastic apm یا sentry هستن ولی دونستن این api های خام میتونه بهتون دید خوبی بده هرچند به صورت روزمره استفاده نکنید.

در ادامه با استفاده از فانکشن mark اومدم یدونه مارک مشخص کردم که در نهایت نتیجه یک instance از PerformanceMark هست که همچین خروجی رو هم میبینیم بعد از log ها.

PerformanceMark {
  name: 'start_perf_check',
  entryType: 'mark',
  startTime: 25.279009,
  duration: 0,
  detail: null
}
PerformanceMark {
  name: 'end_perf_check',
  entryType: 'mark',
  startTime: 3027.833827,
  duration: 0,
  detail: null
}

در اینجا ما name رو میبینیم که اسم mark ما هست و نیازی به توضیح نداره. در حقیقت startTime هم دقیقا لحظه ای هست که اون mark رو ما call کردیم. از لحظه اجرا برنامه تا mark اول 25ms طول کشیده و بعد از 3 ثانیه mark دوم کال میشه که در نتیجه startTime دوم رو 3027ms میبینیم. اینجا یک نکته وجود داره که حدود 3ms از 3 ثانیه بیشتر شده که این خودش نشونه اتفاقات دیگ در runtime باشه و البته موضوع مهم تر این که تضمینی وجود نداره که async job شما دقیقا در تایمی که تعریف کردیم resolve بشه.

نکته بعدی این که mark به عنوان arg دوم یک object میگیره که شما میتونید توضیحات بیشتری اضافه کنید و البته مقدار startTime هم دستکاری کنید که پیشنهاد میکنم این کار نکنید مگر دقیقا میدونید دارید چیکار میکنید.

const metaData = { func: myLogic.name };

const perf1 = performance.mark("start_perf_check", {
  detail: metaData,
});
await myLogic();
const perf2 = performance.mark("end_perf_check", { detail: metaData });

حالا شما اگر این کد رو اجرا کنید اینبار detail دیگه null نیست و metaData obj رو ما میبینیم در لاگ.
طبق گفته داکیومنت در هنگام استفاده از mark همیشه و همیشه مقدار duration برابر با صفر هست و در حقیقت PerformanceMark یک subclass از performanceEntry هست که در آینده بیشتر باهاش آشنا خواهیم شد.
نکته بعدی این که مقدار entryType هم همیشه در این سناریو برابر با mark هست.

پست قبل مربوط به این موضوع : https://news.1rj.ru/str/NodeMaster/197

#Tip #NodeJS

خب ظاهرا در جهت ورژن جدید 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