خواستم تشکر کنم بابت گذاشتن این پست داخل چنلت. ایدی خودت رو پیدا نکردم گفتم اینجا تشکر کنم🧡
https://news.1rj.ru/str/Never_Forget_Semicolon

یکی از نکاتی که به برای بچه های #BackEnd و #FrontEnd به اندازه هم میتونه کاربردی باشه استفاده از static method های Array.from و Array.fromAsync. این نکته هم بگم که Array.fromAsync به تازگی با توجه به آپدیت #V8 در نسخه 22 برای #NodeJS منتشر شده و در نسخه های قبل در دسترس نیست.
حالا کار این متد ها به چه شکل هست با .from شروع میکنیم. شما اگر یک iterable obj داشته باشید شاید بخواید این Object رو تبدیل به Array کنید و معمولا از این تکنیک استفاده میشه.

const arr = [];
for (const v of iterableObj) {
  arr.push(v);
}

این استایل از برنامه نویسی بیشتر به نوعی imperative programming محسوب میشه و در زبان های procedural programming خیلی دیده میشه. با این حال که #JavaScript یک زبان Multi-paradigm هست و این استایل کد زدن مجاز هست ولی خیلی در کامینیوتی مرسوم نیست و کلا بیشتر کد های declarative و ترکیب OOP و Functional استفاده میشه. ( هرچند Functional خالص سخت هست در #JavaScript )
حالا اگر بخوایم کد بالا رو یطوری داشته باشیم که مرسوم تر باشه بین برنامه نویس های #JavaScript، در این سناریو متد های Array.from و Array.fromAsync به کمک ما میاد تا کد ما declarative تر بشه.
حالا برای تبدیل کد بالا کافی هست این کار رو کنید و بووم تمام!

const arr = Array.from(iterable);

اگر بخوام درمورد Array.fromAsync هم بگم این هست که دقیقا به همین شکل کار میکنه و تنها تفاوتش این هست که با async iterable ها و generator ها سازگار هست.

const arr = [];
for await (const v of asyncIterable) {
  arr.push(v);
}

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

const arr = await Array.fromAsync(asyncIterable);

هنوز یک قسمت جالب از داستان مونده بزارید با مثال بهتون نشون بدم.

Array.fromAsync(
  new Set([Promise.resolve(1), Promise.resolve(2), Promise.resolve(3)]),
).then((array) => console.log(array));
// [1, 2, 3]

اگر اینجا دقت کنید میبینید که میتونه سناریو مناسبی برای استفاده از Promise.all باشه ولی استفاده نشده به نظرتون تفاوت چیه؟
با استفاده از Promise.all تمام Promise ها به صورت همزمان تلاش به resolve شدن دارن یعنی داره concurrent انجام میشه اما در این سناریو بدون بلاک شدن event loop به ترتیب Promise ها resolve میشن.
راستی این ویژگی هم از نسخه 1.38 روی #Deno در دسترس بوده و این برای من خیلی جذابه که تیم #Deno اینقدر خوب دارن عمل میکنن. مدتی هست هر حرکتی در اکوسیستم اتفاق میافته #Deno از پرچم داران در سرعت آپدیت و رو به جلو حرکت کردن هست.
#Tip

من یک نظر دارم که استفاده از switch statement به شدت کد رو کثیف میکنه و هروقت کد #backend یا #frontend میبینم که استفاده شده حس خوبی نمیگیرم.

چندین سال هست که به جرات میتونم بگم شاید ۱۰ بار switch statement استفاده نکردم مگر روی legacy کدی باشم که همچین استایلی کد زده شده باشه.

دوست دارم نظر شما هم بدونم که چه فکر میکنید.

https://x.com/imanhpr_media/status/1785700265280102807?t=kv4Mr2FE8_CIDVl__IqclQ&s=09

سوال مصاحبه درمورد #NestJS
شما وقتی با #NestJS و #TypeScript در حال توسعه #BackEnd هستید خب به صورت روتین از Injectable ها در #NestJS استفاده میکنید.
حالا با فرض این که ما یک EmailService داریم که Injectable هست و میخوایم در سرویس پایین اون رو inject کنیم و استفاده کنیم. به کد پایین دقت کنید.

@Injectable()
class MyService {
  constructor(private readonly emailService : EmailService)
}

اینجا همه چی درست و عادی کار میکنه ولی اگر یکم با دقت بیشتری نگاه کنید این کد خیلی غیر عادی هست. باتوجه به این موضوع که در هنگام transpile شدن کد #TypeScript به #JavaScript تایپ ها حذف میشه.
حالا سوال اینجا هست که #NestJS چطور با استفاده از یک type یعنی EmailService متوجه میشه باید چه سرویسی رو inject کنه؟ در حقیقت اینجا از یک type یک logic داره که در برنامه ما استفاده میشه و برسی این black magic میتونه جذاب باشه.

نظراتتون رو کامنت کنید.

#Tip

یکی دیگ از 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