خب دوستان صبح اول هفته خودمون رو با یک خبر امنیتی از #npmjs شروع میکنیم. همونطور که میدونید بار ها درمورد امنیت صحبت کردیم. همه شنیدیم که از یوتیوب و تلگرام و دیسکورد به عنوان storage رایگان استفاده میکنن خیلیا. اینبار حدود 748 پکیج پیدا کردند که شامل فیلم میباشند. البته اگر یکم در #npmjs عمیق تر بشید میتونید کتاب و ... همه پیدا کنید.
فیلم هم ظاهرا شبیهه به جومونگ هست که عکساش رو میتونید داخل پست اصلی ببینید.

منبع :
https://blog.sonatype.com/npm-flooded-with-748-packages-that-store-movies

#Security

همیشه دنبال یک معادل مناسب برای #Python Beautiful Soup در اکوسیستم #NodeJS بودم که نخوام با headless browser ها scrap انجام بدم. امروز این پکیج رو پیدا کردم شما هم اگر دوست داشتید یک چک کنید.
https://www.npmjs.com/package/cheerio

بچه های #FrontEnd و #BackEnd هفته پیش Deno نسخه 1.40 منتشر شد توجه کنید. حالا سوال پیش براتون میاد که چه ربطی به ما داره. دو proposal مربوط به #EcmaScript در این آپدیت نکاتی وجود داره.
همونطور که میدونید Date در #Javanoscript همیشه مشکلات داشته و اکثرا از lib هایی مثل moment و ... استفاده میشد. استاندارد TC39 Temporal وارد Stage 3 شده و Deno ظاهرا اولین Runtime میباشد که این استاندارد رو پیاده سازی کرده و الان میتونید با فلگ unstable ازش استفاده کنید. قطعا به زودی شاهد پیاده سازی ها روی سایر Runtime ها مثل #NodeJS و مرورگر ها برای فرانت خواهیم بود.
لینک مربوطه :‌ https://tc39.es/proposal-temporal/docs/index.html
دقت کنید بهش میبینید ساپورت تقویم فارسی هم داره :)

const now = Temporal.Now.plainDateISO(); // Output => 2024-02-03

const twoDay = Temporal.Duration.from("P2D"); // Output => 2024-02-05

const twoDayLater = now.add(twoDay);
twoDayLater.toLocaleString("fa-Fa"); // Output => ۱۱۴۰۲/۱۱/۱۶

// Support for persian calender
twoDayLater.withCalendar("persian")

حالا این رو اینطور ران کنید.

deno run --unstable-temporal main.ts

موضوع بعدی مربوط به استاندارد TC39 Decorators هست. باتوجه به محبوب بودن Decorator ها در transpiler ها بعد از سالها بلاخره این هم وارد Stage 3 شد. یعنی به زودی شاهد Decorator ها در #JavaScript به صورت Native خواهیم بود. این ویژگی الان سمت Deno در آپدیت 1.40 اضافه شاده و به زودی شاهد اومدنش در مرورگر ها هم خواهیم بود. البته فایل ها #JavaScript محدودیت داره بخاطر پیاده سازی سمت انجین V8
لینک مربوطه : https://github.com/tc39/proposal-decorators

چند وقت پیش درمورد اضافه شدن impoer.meta.dirname و import.meta.filename در #NodeJS صحبت کردیم. در آپدیت 1.40 این ويژگی به Deno هم اضافه شد تا سازگاری با استانداردها و Runtime های دیگه حفظ بشه.
لینک پست : https://news.1rj.ru/str/NodeMaster/123
بلاگ پست مربوطه به این آپدیت دینو : https://deno.com/blog/v1.40

یکی از Flag هایی که به #NodeJS مدتی هست اضافه شده یعنی ورژن v20.6.0 که خیلی هم کاربردی هست مربوط به .env ها هست.
شما با فلگ زیر میتونید بدون استفاده از پکیج هایی مثل dotenv فایل های .env رو به راحتی لود کنید داخل پروژه خودتون.

node --env-file=.env --env-file=.development.env index.js

این ویژگی یکی از ویژگی های خوب Deno هست که به صورت builtin قرار داشت و تیم #NodeJS هم با تصمیم خوبی گرفتند که این رو اضاف کردند.
#Tip

سلام و خسته نباشید.
یک تیم ایرانی در حال توسعه یک فریم ورک با #Deno هستند و من با سازنده این فریمورک صحبتی داشتم.
لینک گیتهاب :‌https://github.com/MiaadTeam/lesan#many-thanks-to-those-who-supported-us

نقل از سازنده :
یک وب‌سرور بعلاوه ODM بر روی MongoDB، که با الهام از GraphQL مدیریت دریافت داده‌ها رو به سمت Client سپرده ولی خیلی از مشکلات اون رو نداره.
و از همه مهمتر یه تعریف جدید از رابطه‌ی بین داده‌ها ارائه می‌ده، که باعث میشه دریافت داده‌ها بسیار سریعتر انجام بشه و مدیریت اونها قابل فهم‌تر باشه. این فریم‌ورک تمام رابطه‌ها رو بدون دردسر امبد میکنه و سرعت خواندن اطلاعات توش وحشتناک بالاست.
(بنچمارک رو ببینید https://miaadteam.github.io/lesan/#benchmarks).
نوع نگاه لسان به رابطه‌ها باعث شده داده‌ها و کوئری‌ها برای دریافت اونها ساده سازی بشند، به همین خاطر کل فرآیند از کدنویسی تا لایه کش حتی دیتا ماین هم ساده میشه.

من خودم فرصت نکردم دقیق چک کنم ولی اگر دوست داشتید یک سر بزنید بهش نظراتتون رو بگید.

داکیومنت :
https://miaadteam.github.io/lesan/

ارتباط با تیم : @syd_amir

مدتی هست در گروره کانال @NodeMasterGP بچها خیلی درمورد ماهیت Async بودن و Single Thread بودن #NodeJS صحبت میکنند. یکی از env های استاندارد UV_THREADPOOL_SIZE هست. همونطور که میدونید پشت انجین #NodeJs یک کتاب خانه Native برای هندل کردن کار ها به صورت async میباشد. این native lib وظیفه دارد تا یک interface یکسان برای تمامی سیستم عامل ها به وجود آورد. بعضی از api ها به صورت کلی به صورت Sync هستن ولی معادل Async اون رو ما داخل NodeJS میبینیم. به عنوان مثال "node:crypto" برای ما cps async api داره ولی ذات اونها sync هست. حالا سوال پیش میاد که چطور چیزی که sync هست رو async کنیم.
در اینجا libuv یک راه حل هوشمندانه داره. با استفاده از Thread Pool pattern در MultiThreading و ایجاد صف از کار هایی که باید همزمان انجام بشوند api های sync رو تبدیل به async میکنه. هرکدوم از این ترد ها یک کار رو برمیداره انجام میده و دوباره میره سراغ کار بعدی. حالا شما میتونید تعداد thread هایی که در این استخر وجود داره رو کنترل کنید.( خیلی شبیه به معماری master slave هست )

export UV_THREADPOOL_SIZE=8
node main.js

تعداد thread های در pool به صورت پیش فرض ۴ هست. معمولا طبق best practise هایی که من مطالعه داشتم به صورت کلی میگن به تعداد هسته های CPU خوبه. اما اگر بخوایم دقیق تر به این موضوع نگاه کنیم فاکتور های خیلی زیادتری داریم که من خودم هنوز دقیق نتونستم مطالعه کنم درموردشون. سخت ترین کار پیدا کردن همین بالانس هست که یک اصول داره.

با استفاده از این env میتونیم رفتار #NodeJS رو خیلی دقیق تر نگاه کنیم در سناریو های مختلف.
این موضوع رو در‌ آینده حتما در یک ویدیو دقیق تر نگاه میکنیم تا رفتار های جالب #NodeJS رو در سناریو های مختلف ببینیم.

دوستان honeypot.io که در زمینه کاریابی فعالیت میکنه یک مستند درمورد #NodeJS داره میسازه که میتونید تریلر این مستند رو اینجا ببینید.
https://youtu.be/SfWPqr04srM?si=siu0S0JNd4QZnSxD

هر روز یک چیزی هست که ما رو سوپرایز کنه. یک Full Stack Framework برای #NodeJS دیدم که خیلی جالب هست.
https://wasp-lang.dev/
ظاهرا شبیهه به Prisma ORM که زبان خودش رو داره شما کل app با کد های Custom خودتون رو در یک فایل .wasp مینویسید و اون app شما رو میسازه.

مرسی از همتون رفقا واقعا دمتون گرم 600 نفر شدیم.❤️ 🎉
خیلی خیلی خوشحالم که تونستیم باهم یک کامینیوتی کوچیک تشکیل بدیم و رشد کنیم امیدوارم موفق باشید همگی❤️👍

دوست دارم یکم درمورد Dependency injection صحبت کنم. یکی از پایه ای ترین Pattern ها که اوایل در زبان های Static Type خیلی محبوب شد ولی به زبان های Dynamic Type هم راه پیدا کرد. هر گوشه ای که در صنعت نگاه کنید این تکنیک رو میبینید که در حال استفاده است. از فریم ورک های محبوب مثل Spring boot در #Java و NestJS در #NodeJS و Angular در کد های #FrontEnd #JavaScript . حالا سوال پیش میاد چرا از این تکنیک استفاده میکنن؟
یک اتومبیل رو در نظر بگیرید از اجزای زیادی تشکیل شده است این اجزا به هم وابستگی های ( Dependency ) زیادی دارن اما نحوه قرار گرفتنشون در کنار هم خیلی جالبه. به این شکل که اگر قطعه ای خراب شد نیاز نیست کل ماشین رو بندازیم دور و به راحتی میتونیم قطعه مورد نظر رو جایگزین با قطعه جدید کنیم.

یک موضوع دیگ بنظرم یوتیوب برید ویدیو راجع به خط تولید ماشین ها نگاه کنید. میبینید که در استیج های مختلف با این که ماشین هنوز آماده نیست قطعات کوچک تر رو جدا تست میکنن ( Unit Test ) بعد ماشین یا که کامل شد کل ماشین رو یکجا تست میکنند ( End2End Test ). حالا این تکنیک اگر درست استفاده بشه فرایند تست نوشتن رو خیلی براتون راحت میکنه. دوستان تست نوشتن برای برنامه ای که مینویسید از خود برنامه سخت تره. یکی از محدود خط کش هایی که میتونیم باهاش معیار کد خوب و بد رو مشخص کنیم کدی هست که بشه براش تست نوشت و کدی که بشه low mock test انجام داد.

معمولا همه جا راجع به کد #SOLID صحبت میکنن اما این رو هیچ وقت نمیگن که اگر به دنبال #SOLID شدن حرکت میکنید بدون Dep Injection تقریبا غیرممکن هست. نکته جالب این که خیلی از تازه کار ها در مفاهیم Object Orinted مشکل دارند به طوری که درک مفهومی مثل Abstraction برای تازه کار ها یکم سخت هست. اما اگر به این Pattern در آموزش ها دقیق تر پرداخته میشد. بعد از یک مدت کار کردن به این موضوع میرسید که ۴ اصل Object Orinted خیلی به صورت طبیعی براتون منطقی میشه. مخصوصا تکنیک Abstraction که ابزار ما مثل آچار برای مکانیک ها هست که بهشون کمک میکنه قطعات یک اتومبیل رو عوض کنن ( ما هم با Abstraction میتونیم برنامه خودمون رو تبدیل به قطعه های کوچک تر کنیم و این قطعات رو در صورت نیاز تعویض کنیم )

صحبت کردن در مورد این مفاهیم یکم پیچیده هست به دلیل این که خیلی با مفاهیم دیگ مرتبط هستن. چند وقت پیش یک پست گذاشتم که گفتم اگر میخواید فقط یک چیز از این چنل یاد بگیرید این رو یاد بگیرید. اون پست اینجا خیلی مرتبط هست ولی خب به دلیل طولانی شدن کاری بهش نداریم فقط اشاره کردم خودتون به عنوان تمرین یکم فکر کنید روش.
https://news.1rj.ru/str/NodeMaster/137

از اونجایی که دوست دارم به جای ماهی دادن، ماهیگیری یاد بدم از اینجا به بعد درمورد این که چطور یک مفهومی که هیچی ازش نمیدونیم رو باهم یادبگیریم.
در کتاب های الگوریتم یکی از اولین الگوریتم هایی که درموردش صحبت میکنن Divide and conquer ( معادل فارسی تفرقه بینداز و حکومت کن ) هست. این الگوریتم محدود به کامپیوتر فقط نیست و میتونید در یادگیری خیلی استفاده کنید. و یک نمونه رو اینجا باهم میبینیم. این الگوریتم اینطور هست که اگر مسئله ای داریم بیایم و اون رو مسئله های کوچک تر تبدیل کنیم و حال کنیم.
خب به این شکل هست که برای درک بهتره Dependency injection بهتره ما اول یاد بگیرم خود Dependency چی هست. بعد injection رو یاد بگیریم. بعد فکر کنیم که ترکیب این دوتا چطور میشه Dependency injection حالا به جای یک مسئله بزرگ ۳ مسئله کوچک تر داریم با ترتیب میتونیم حل کنیم. خب تبریک میگم الگوریتم Divide and conquer هم یاد گرفتید.

بریم برای سوال اول. Dependency چیست ؟

function syncLogic1() {}
function syncLogic2() {}

function job() {
  syncLogic1(); // dependency
  // Some codes
  syncLogic2(); // dependency
}
function main() {
  job(); // dependency
}

main();

ما دوتا لاجیک داریم که باید به ترتیب انجام شوند به عنوان مثال و فانکشن job کاری هست که باید انجام بشه. وقتی ما از یک function یا class به صورت مستقیم در یک function یا class دیگ استفاده میکنیم در حقیقت داریم وابستگی ( Dependency ) شدیدی ایجاد میکنیم. الان فانکشن main به job وابستگی داره و job به syncLogic1 و syncLogic2. اگر بخوایم یک مثال قابل لمس تر بزنیم

import { randomInt } from "node:crypto";

class SendOTP {
  sendSms() {
    const number = randomInt(1000, 9999); // dependency
    // Api call to send sms
  }
}

کد بالا فرض کنید میخوایم کد otp ارسال کنیم با استفاده از randomInt یک کد میسازیم و چون مستقیم از این فانکشن استفاده کردیم در SendOTP class وابستگی ایجاد کردیم.

به دلیل طولانی شدن ادامه بحث رو در پست های بعد عمیق صحبت میکنیم.

#Tip پارت اول.

اگر به وب سایت #TypeORM یک سر بزنید همون صفحه اول این مثال رو میبینید. اینجا یک pattern خیلی کاربردی داریم که خیلی کمتر بهش توجه میشه.

const user = new User()
user.firstName = "Timber"
user.lastName = "Saw"
user.age = 25

این چه پترنی هست؟ کامنت کنید صحبت کنیم
#Tip

دوستان. این آگهی استخدام از بچهای گروه خودمون هستن. چک کنید حتما
#Work

https://jobinja.ir/companies/barsaweb/jobs/ARrH/%D8%A7%D8%B3%D8%AA%D8%AE%D8%AF%D8%A7%D9%85-javanoscript-mid-level-back-end-developer-%D8%AF%D8%B1-%D8%A8%D8%B1%D8%B3%D8%A7%D9%88%D8%A8

یکی از مشکلاتی که میتونه داخل تیم ها بین #FrontEnd و #BackEnd باشه داشتن Api Doc مناسب هست. اکثرا همه از #Postman استفاده میکنن ولی به دلیل مشکلاتی که داخل ایران داریم و نمیتونیم از ویژگی های پولی این app در تیم ها استفاده کنیم. یکی از این ویژگی ها مهم ایجاد Workspace مشترک بین اعضای تیم هست. در تیم خودمون دنبال یک راه حل برای حل این مشکل بودیم که رسیدیم به #Hoppscotch. یک جایگزین مناسب برای #Postman که کاملا opensource هست و تمام ویژگی هایی که یک تیم توسعه نیاز داره به صورت رایگان در اختیار شما قرار میده. نکته خیلی خوب دیگ راجع به این ابزار توانایی self host کردن درون سازمانی هست که کامل وابستگی شما رو میتونه از عوامل بیرونی از بین ببره.

البته یک نکته مثبت دیگ این که نه تنها برای تمامی پلتفرم ها app native داره. بلکه نسخه وب هم داره که نیاز به نصب نداره.
اگر در تیمتون توانایی استفاده از ویژگی های پولی postman رو ندارید و دنبال راه حل مناسبی برای کمتر کردن رفت آمد بین تیمی برای گرفتن collection های بروز از api doc ها هستید قطعا یک نگاهی به این بندازید.

https://hoppscotch.io/

در پست قبل درمورد Dependency صحبت کردیم و یاد گرفتیم که Dependency چیست؟ سوال دومی که قرار بود درموردش صحبت کنیم این بود که Injection چیست؟ به مثال پایین دقت کنید.

import { randomInt } from "crypto";

// Normal Version
function generateOtp() {
  const otp = randomInt(1000, 9999); // dependency
  return otp;
}

// Injected Version
function generateOtp(fn) {
  const otp = fn(1000, 9000);
  return otp
}
const result = generateOtp(randomInt);

در ماشین ها یک قطعه داریم به اسم injector ( فارسی میگن انژکتور در حقیقت اینجکتور هست ). خب انجین نیاز به سوخت داره و این وسیله وظیفه inject کردن سوخت به انجین داره یعنی از این زاویه نگاه کنیم که انجین به سوخت وابستگی (Dependency) دارد و injector سوخت رو inject میکنه به انجین و حالا رسیدیم به خود Dependency Injection. میشه گفت این قطعه فریمورکی هست که کار Dependency Injection رو انجام میده برامون مثل #NestJS در #NodeJS و #Spring در #Java.
اینجا یک لاجیک ساده داریم که کد otp میسازیم. در نسخه اول خیلی ساده میایم فانکشن randomInt رو به عنوان Dependency در فانکشن generateOtp استفاده میکنیم. اما در نسخه دوم بجای این که مستقیم از randomInt استفاده کنیم اون رو از طریق argument به generateOtp پاس میدیم و از طریق reference که بهش داریم کد Otp رو generate میکنیم. در حقیقت ما فانکشن randomInt رو در فانکشن generateOtp با این کار که از طریق argument بهش inject ( تزریق ) کردیم.

پس اگر بخوایم جمع بندی کنیم که Injection چیست. یعنی یک object رو از طریق های مختلفی مثل argument ها در function پاس بدیم و مستقیم استفاده نکنیم.
حالا اگر تعریف بالا رو کامل تر کنیم به Dependency Injection میرسیم. به این صورت که بجای استفاده از مستقیم از Dependency اون رو به روش های مختلف مثل مثال دوم داخل object مورد نظر inject کنیم. یعنی در حقیقت generateOTP به randomInt وابستگی دارد و وقتی ما از طریق argument به randomInt رو inject میکنیم به generateOtp به این کار میگیم Dependency Injection.

حالا در برنامه نویسی OOP وقتی از class ها استفاده میکنیم. نکات دیگه ای هم هست که باید بهشون توجه کنیم
- singleton design pattern خیلی استفاده میشه و شما اگر از هر DI framework استفاده کنید روشی برای کنترل این موضوع به شما میده.
- فرایند Injection از طریق Constructor
- فرایند Injection از طریق setter method

اگر یکم بخوایم دقیق تر به DI نگاه کنیم در حقیقت DI یک نوع خیلی سفارشی سازی شده از IOC Pattern هست ( Inversion Of Control ). اگر یکم بخواید خودتون مطالعه کنید این اصطلاح DI/IOC رو خیلی کنار هم میشنوید. مثال هایی از IOC رو میتونید در سرتاسر اکو سیستم برنامه نویسی ببینید.

به صورت کلی در این پست با مفهوم DI به صورت خیلی ساده آشنا شدیم. پست بعدی به DI در برنامه نویسی Object Orinted نگاه میکنیم و درمورد نکات بالا مفصل حرف میزنیم و صد البته با Poor man di آشنا میشیم تا di container رو بتونیم بهتر یاد بگیریم
درمورد IOC هم در آینده به صورت کامل جدا صحبت میکنیم چون خیلی مهم هست و نباید به سادگی از کنارش عبور کنیم.

پارت دوم
#Tip

یکی از نکاتی که خیلی بدرد بچه های #BackEnd و #FrontEnd در #JavaScript میخوره استفاده از AbortController Signal هست. گاهی اوقات شما یک Async job رو شروع میکنید حالا به هردلیلی قصد دارید در صورتی که اگر اون async function هنوز reslove نشده اون رو کنسل کنید. در همچین سناریو هایی AbortController به کمک شما میاد.
یکی از مثال هایی که میتونید ببینید به عنوان مثال استفاده از fetch هست.

const ac = new AbortController();

setTimeout(() => {
  ac.abort();
}, 20);

const response = await fetch("https://httpbin.org/get", {
  signal: ac.signal,
});

وقتی شما از AbortContoller استفاده میکنید یک object با دوتا attr میگیرید. یک method برای ارسال سیگنال و یکی خود سیگنال. همینطور که میبینید ما یک setTimout گذاشتیم که بعد از 20ms سیگنال رو ارسال کنه و چون eventloop block نشده ما http request رو با fetch ارسال کنید و بعد از ارسال شدن http request که 20ms گذشته ما سیگنال کنسل رو ارسال میکنیم.

حالا اگر بخوایم یک مثال بزنیم که بیشتر برای #NodeJS هست برای درک بهتر. همونطور که اول گفتم خیلی از Standard api های خود #NodeJS همچین interface رو دریافت میکنن به عنوان مثال Stream و worker_thread ها نمونه ای از این موضوع هستند.

const ac = new AbortController();
setTimeout(() => ac.abort(), 20);

fs.createReadStream("./samplefile.txt", { signal: ac.signal }).pipe(process.stdout);

همینطور که میبینید یک ReadStream درست کردم برای خوندن یک فایل و مثل fetch یک abortsignal بهش پاس دادم بعد دوباره با استفاده از setTimeout حدود 20ms بعد سیگنال کنسل فرستادم. و استریم رو قطع کردم. حالا درمورد استریم سناریو های دیگ هم وجود داره برای کنسل کردن که کاری به اون ها در اینجا نداریم و موضوع بحث ما نیست.

چرا باید از این روش استفاده کنیم؟
اگر پروژه کوچیک دارید اصلا ارزش استفاده نداره بخاطر پیچدگی که اضاف میکنه این manage کردن سیگنال ها. ولی اگر پروژه با load زیاد دارید به دلیل این که single thread eventloop داریم هرچقد بتونیم کار های اضافی رو از eventloop کمتر کنیم برنامه بهتری خواهیم داشت. خیلی وقت پیش درمورد mechanical sympathy صحبت کرده بودم. همچین تکنیک های ریزی که برای Optimization استفاده میشه ممکنه به صورت روزمره کاربردی نباشه ولی دونستن اون ها خیلی به ما کمک میکنه که بتونیم برنامه بهتری بنویسم.
#Tip

امروز هم با یک موضوع دیگ اومدم که خیلی برای تیم های #BackEnd و #FrontEnd کاربردی هست مخصوصا اگر تیم بزرگ باشه. اگر در تیم های خودتون پکیج داخلی #JavaScript توسعه دادید. به هردلیلی بخشی از اون API اگر Depricate شده اون رو بهتره در ورژن بعدی حذف نکنید. و بهتره با deprecated tag در jsdoc استفاده کنید و به هم تیمی های خودتون توضیح بدید که چرا نباید از این API استفاده کرد و روش جدید استفاده از معادل API جدید هم حتما فراموش نشه.

/**
 * @deprecated since version 2.0
 */
function old() {
}

حالا بچه های #NodeJS یک قدم میتونن فراتر برن و با استفاده از یک function کمکی به runtime هم بگن که این deprecate شده و وقتی پروژه اجرا میشه با #NodeJS به برنامه نویس با هشدار DeprecationWarning اطلاع میده که موضوع رو برسی کنه.

import util from "node:util";
/**
 * @deprecated since version 2.0
 */
function old() {}

old = util.deprecate(old, "since version 2.0");
export { old };

حالا وقتی پروژه رو اجرا کنید همچین خروجی میبینید.

$ node main.js                    
(node:163509) DeprecationWarning: since version 2.0

البته اگر این موضوع کافی نبود میتونید با استفاده از --trace-deprecation فلگ جزیات بیشتری از stack trace ببینید و برید موضوع رو دقیق تر برسی کنید.

node --trace-deprecation main.js

#Tip

الان دقت کردم این بخش میبینم یک تکنیک گاها کاربردی استفاده شده. مخصوصا برای تست. حتی در مواقع ضروری در production هم از این استفاده میکنن. راهنمایی میکنم گاهی در runtime نیاز هست بدون این که به function یا method اورجینال دست بزنیم باید اون رو جایگزین کنیم. اگر دقت نکنیم خیلی هم میتونه خطرناک باشه.
زیر این پست کامنت بزارید درموردش صحبت کنیم.
بعدا درموردش با جزیات بیشتری صحبت میکنیم.

- این هم بگم که decorator نیست.

اگر از #NodeJS به صورت حرفه ای استفاده میکنید. همینطور که میدونید چندسالی هست که #ExpressJS فقط روی حالت maintenance بوده و هیچ آپدیت بزرگی نداشته. قرار بود سال 2020 ورژن 5 از این فریمورک محبوب منتشر بشه ولی خب الان 4 سال گذشته و خبری نیست هنوز!
ظاهرا چند هفته اخیر در github بعضی از افراد تاثیر گذار در این پروژه شروع به صحبت درمورد این پروژه و آینده اون کردن و یک نقشه راه تقریبی برای ورژن های 5 , 6 و حتی 7 هم منتشر کردن که میتونید جزیات بیشتر هم در این issue ببینید.
https://github.com/expressjs/discussions/issues/160
یک دورهمی هم داشتن که صحبت هاشون رو گفتن که میتونید از این لینک یوتیوب مشاهده کنید.
https://www.youtube.com/watch?v=beWATMWGu5Q

همین موضوع باعث شده که کامینیوتی #NodeJS از Express فاصله بگیرین و به سمت Fastify حرکت کنن. در حال حاظر من به شخصه برای پروژه جدید به هیچ عنوان از Express دیگه استفاده نمیکنم و صدرصد Fastify رو ترجیح میدم. به دلایل زیر.
- سرعت بالاتر حدود ۸ برابر
- اکوسیستم مناسب از package های 3rd party که توسط تیم اصلی maintain میشه. و هر نیازی رو برای توسعه backend رفع میکنه.
- هسته کوچک اما کاربردی که خیلی توسعه پذیر هست.
- از همه جالب تر به دلیل ساختاری که داره مهاجرت از monolithic به microservice درصورت شناخت کافی از این فریمورک خیلی راحت تر صورت میگیره.

درکل خبر خوبی بود برای جامعه #NodeJS و باید ببینیم در آینده چه اتفاقی خواهد افتاد.

پیج رسمی #NodeJS در توییتر از mascot logo جدید برای Node رونمایی کرد.
اسمش رو گذاشتن Rocket turtle 🐢🚀

https://twitter.com/nodejs/status/1759953849849167878?t=pfq8FarAeV8nE_RJ7uLGbg&s=19

نکته باحال اون لوگو مشکی Nodejs بالا هست که من خیلی خوشم اومد