دیتابیس های 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

فرض کنید یک وب سایت فروشگاهی دارید و در حال توسعه API هستید که میخواید وضعیت سفارش ها رو در پنل ادمین نمایش بدین. کارفرما از شما میخواد که Status های درحال انتظار در اول قرار بگیره و بقیه هم بعد از اون. در این حالت با این Query کارتون رو میتونید راه بندازید.

ORDER BY 
    CASE WHEN Status = 'WAIT' THEN 0 ELSE 1 END,
    Date DESC

#Tip #SQL

در حال مطالعه داکیومنت Tron هستم برای کار با Smart Contract ها و ... که یک نکته خیلی ریز در اصل یک کلمه خیلی توجهه من رو جلب کرد. به عکس بالا دقت کنید، مخصوصا به بخش highlight شده، مخصوصا به کلمه "compatible". این کلمه خیلی کلمه مهمی هست.

حالا بخوام یکم Context بدم درمورد موضوع این هست که Smart Contract های ERC-20 که روی شبکه ETH هستن باید کدشون کاملا سازگار باشه با TRC-20 که روی شبکه Tron هست. و اینجا اگر دقت کنیم دوباره میرسیم به این جمله معروف.
"program to interfaces, not implementations"

چند ماه پیش درمورد دلیل این که چرا درک این جمله اینقدر مهمه صحبت کردم و پست هایی هم داشتیم. حالا داستان "compatible" چیه ؟ اگر شما برید کد Smart Contract مربوط به USDT رو چک کنید متوجه کلمه های ERC میشید که این مربوط به شبکه ETH هست ولی روی شبکه Tron.
خیلی ساده بخوام بگم ما مفهوم این جمله رو داریم در Scale خیلی بزرگ میبینیم و سرنخ این موضوع در حد یک کلمه همینقدر ریز هست.

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

به تازگی نسخه جدید LTS یعنی 20.15 برای #NodeJS منتشر شده.
یکی از ویژگی های کاربردی که اضافه شده مربوط به "node:test" هست. قابلیت test plan هست

test('top level test', t => {
  t.plan(2);
  t.assert.ok('some relevant assertion here');
  t.subtest('subtest', () => {});
});

به این صورت کار میکنه که اگر تعداد subtest ها و یا assertion ها برابر با plan نباشه تست به خطا میخوره و این موضوع در unit test خیلی میتونه کاربردی باشه به دلیل این که میتونه تست ها رو strict تر کنه.

موضوع بعدی اضافه شدن یک flag جدید هست

--inspect-wait

یکی از مهمترین flag های #NodeJS در حقیقت خانواده flag های inspect هست. حالا سوال پیش میاد چرا؟ با کمک این فلگ ها میتونید با استفاده از ابزار های کمکی مثل chrome dev tools که یک debugger مربوط به انجین V8 داره به جنگ Bug ها و Bottleneck ها برید. برای Bottleneck یک ابزاری که اینجا در دسترس هست flamegraph هست که فارغ از زبان تو هر زبان برنامه نویسی میتونی این مدل نمودار رو ببینی ( لازمه بگم کسایی که flamegraph بلدن بخونن واقعا آدم های قابل احترامی هستن ).
یکی دیگه از بزرگترین و مهمترین ابزار هایی که کمک میکنه و میتونه ساعت ها زندگیتون رو نجات بده Heap Profiler هست. کابوس هر برنامه نویس #NodeJS قطعا Memory leak هست و پیدا کردنش خیلی سخته. اما اگر از Heap Profiler درست استفاده بشه خیلی سریع میشه Memory leak ها رو پیدا کرد.

چندماه هست دوست دارم درمورد inspect عمیق بشیم ولی متاسفانه فرصتش هیچ وقت برام پیش نیومده. ولی قطعا یک روز این موضوع رو عمیق میشیم.

#Update

یک خورده دارم #React مرور میکنم برای پروژه شخصی. یک موضوعی که به ذهنم اومد این هست که چطور موقع هندل کردن event ها با handler function ها چطور stack trace تمیزی داشته باشیم.
در این پست درمورد این موضوع و این که چطور stack trace تمیزی داشته باشیم با مثال #Express روی #NodeJS صحبت کردیم.
https://news.1rj.ru/str/NodeMaster/228
در این پست هم راجع به Reflection اشاره ای کردیم.
https://news.1rj.ru/str/NodeMaster/121

حالا شما component زیر که خیلی ساده هست رو در نظر بگیرید

function SimpleComp() {
  function clickHandler() {
    console.log("handler fn :", clickHandler.name);
  }
  return <button onClick={clickHandler}>click here!</button>;
}

بزارید همین اول بگم این نکته شاید خیلی زیاده روی باشه و نیاز نباشه ولی خب میتونه برای درک بهتر Reflection درنظر گرفتش. تا اینجا باتوجه به چیزایی که میدونم stack trace خوبی خواهیم داشت به دلیل این که clickHandler اسم داره.
سناریویی رو در نظر بگیرید که دارید روی یک سری دیتا loop میزنید و برای هر Entity که دارید یک clickHandler ایجاد میکنید. سوال پیش میاد وقتی روی یکی از این function ها کلیک و call میشه چطور بدونیم کدوم call شده دقیق؟
۱. راه حل ساده تر و همیشه جواب log کردن هست.
۲. راه حل پیچیده تر کمک از Reflection و تغییر اسم function در runtime.
دوستان لزوما نیازی نیست از Reflection استفاده کنید. با log کردن صحیح نیازی اصلا ندارید و فقط این روش پیچدگی بیهوده اضاف میکنه و صرفا برا عمیق شدن داریم میریم جلو.

function SimpleComp({ id }) {
  function clickHandler() {
    console.log("handler fn :", clickHandler.name);
  }

  Reflect.defineProperty(clickHandler, "name", {
    value: clickHandler.name + "_" + id,
  });
  return <button onClick={clickHandler}>click here!</button>;
}

در اینجا من اومدم به اسم فانکشن Id که به عنوان prop اومده رو در runtime اضافه میکنم و خب این دقیقا معادل همچین چیزی میشه.

function clickHandler_2 (){}

اسم فانکشن به صورت عادی یکی از چیزایی هست که زمان compile time ( یا اینجا dev time میشه بهش گفت هرچند خیلی مرسوم نیست) مشخص میشه و خب وقتی چیزی رو در این زمان داشته باشیم dynamic کردنش نزدیک به غیرممکن هست.

حالا اینجا Reflection بهمون کمک میکنه که در runtime یک چیزی که به صورت عادی دردسترس نیست رو تغییر بدیم مثل name atter برای function ها که در این مثال دارید میبینید و دقیقا این موضوع معادل کد clickHandler_2 هست با این تفاوت که در runtime ایجاد میشه و نه compile time.

#Tip

دوستان که با من کم و بیش درمورد roadmap و یا نظرم رو درمورد مسیرشون پرسیدن همه میدونن من چقدر شخصا روی مبحث database و db design خیلی تاکید زیادی دارم.

در این توییت یک کتاب که مدتی هست دارم میخونم معرفی کردم و نکاتی هم کلی گفتم.
https://x.com/imanhpr_media/status/1808176854945177927?t=6qvq2I-HaKufcJh4a0KGSQ&s=19

این کتاب خیلی کتاب با ارزشی هست و برا من حکم یک سلاح مخفی داره و خب باعث competitive advantage زیادی برای من شده.

#Book

باورم نمیشه مفهوم به این عمیقی در CS این روزا ها میشه بهش نگاه سیاسی داشت.
این توییتم درمورد halting problem توضیح دادم. خیلی زیاد یادم نیست در این مورد و خیلی خلاصه و ساده سعی کردم توضیح بدم که هر خواننده ای بتونه بخونه. ولی در کل برای شما میتونه یک سرنخی باشه برای عمیق تر شدن در این موضوع.
https://x.com/imanhpr_media/status/1808831653323608501
#CS #Tip

ظاهرا به صورت std قراره sqlite به #NodeJS اضافه بشه. خبر جالبی هست.
اینجا میتونید اطلاعات بیشتر رو دنبال کنید.
https://github.com/nodejs/node/pull/53752
#NodeWeekly

من شخصا به عنوان یک #Python Hater دو آتیشه هستم.
ولی یک چیزی داره و عجیب خوب هست. حداقل من تا حالا شبیهش رو داخل هیچ اکوسیستم دیگه ای ندیدم و اگر شبیهش رو میشناسید معرفی کنید خوشحال میشم.

این ویژگی خیلی واقعا خفن pickle std برای #Python هست. در حقیقت pickle یک serialization format مثل #JSON هست و مثل #Protobuf یک فرمت binaray هست. حالا سوال پیش میاد چه نکته ای داره.
شما به pickel هر object در اکوسیستم #Python رو میتونید serialize کنید. هر Object با تمام پیچدگی ها custom که داره. بزارید با مثال توضیح بدم.
تصور کنید یک JSON دارید و اون رو میخواید map کنید به یک class و خب معمولا با Factory ها و به شکل های مختلف این اتفاق میافته.

class User {
  constructor(name) {
    this.name = name;
  }
  static FromJsonString(input) {
    const result = JSON.parse(input);
    return new User(result.name);
  }
}

const runTimeInput = '{"name":"imanhpr"}';
const user = User.FromJsonString(runTimeInput);

console.log(user instanceof User);
console.log(user.name);

همه چی خیلی منطقی کار میکنه در این سناریو. نکته جالب که اینجا و توجه بهش جالبه این هست که در اینجا به صورت ذاتی هیچ metadata وجود نداره که مشخص بشه مقدار runTimeInput واقعا از جنس User هست و معمولا با استفاده از validation های مختلف و factory متد ها باید مشخص کنیم. اگر بخوایم یک سناریو دیگ رو برسی کنیم که یکم پیچیده تر باشه. شما به هردلیل منطقی یا غیرمنطقی تصمیم داری یک function که در نهایت یک object هست رو serialize کنید. چطور این کار میکنید؟

function hello() {
  console.log("hooo");
}
console.log(JSON.stringify(hello));

باتوجه به این که در #JSON به طور کلی هیچ طوره فرمت استانداردی وجود نداره برای این کار منطقی هست کد بالا کار نکنه. ( البته با trick همین کد بالا رو میتونید کاری کنید که بشه ولی کاری به اون سناریو نداریم :) )
یک سناریو پیچیده تر اینه که شما یک object داشته باشید که property denoscriptor های اون رو دست کاری کردین چطور میخواین بدون ست کردن flag یا نشانه در هنگام serialize کردن و بعد از دریافت همون object متوجه بشید که property denoscriptor رو چطور باید ست کنید.

کلا بخوام خلاصه و جمع بندی کنم هرچیزی که مختص object هست که در runtime وجود داره مثل انواع reflection ها و property denoscriptor و method ها و ... .
اینجا هست که pickel خودش رو نشون میده.

import pickle

class NumberOne:
    def __get__(self, obj, objtype=None) :
        return 1


class User:
    __name = "iman"
    one = NumberOne()

    @property
    def name(self):
        print("hello from getter")
        return self.__name
    
    def __eq__(self, value: object) -> bool:
        if isinstance(value , User) and self.__name == value.__name:
            return True
        return False
    
    def __str__(self) -> str:
        return f'User(name={self.__name})'

def hello():
    print("hello from function")

# instance sterilization
user_instance_bin = pickle.dumps(User())
run_time_user = pickle.loads(user_instance_bin)
print("user instanceof User :",isinstance(run_time_user , User))
print("user object :" ,  run_time_user)
print("equality check :" , run_time_user == User())
print("getter invocation :" , run_time_user.name)

# function sterilization
function_bin = pickle.dumps(hello)
run_timefn = pickle.loads(function_bin)
run_timefn()

# class sterilization
cls_bin = pickle.dumps(User)
runtime_cls = pickle.loads(cls_bin)
print("class check:" , issubclass(runtime_cls , User))

# << Exciting part >>
print("WTF:",run_time_user.one)

در اینجا شما هر جسم قابل لمسی رو در #Python میتونید serialize کنید و مستقیم با خوندن همون data یک object قابل لمس در runtime با تمام metadata ها دریافت کنید. از class گرفته تا یک gatter method که با decorator هست تا انواع magic method ها یا به قول #Pythonic ها dunder method.
از همه جالب تر اون بخش آخر هست که یک Python Denoscriptor رو هم کنار object های User گذاشتیم و میبینیم اون هم به صورت کامل میبینیم. اگر بخوام خلاصه در یک جمله توضیح بدم رسما با اینکار انگار از یک object دارید فایل exe میسازید به جای یک برنامه بزرگ!

نکته بعدی این که این pickel استاندارد مربوط به کد های python هست و جای دیگ تقریبا میشه گفت کاربردی نداره.

https://docs.python.org/3/library/pickle.html

خدمت شما بگم #Deno 1.45 به تازگی منتشر شده. یکی از نکات خوبی که من در این آپدیت دیدم قابلیت Monorepo هست که اضافه شده.
و البته std هم داره نزدیک به stable شدن میشه.
و صد البته با فعال کردن flag زیر میتونید دسترسی به ویژگی های جدید #Deno در ورژن 2 داشته باشید.

DENO_FUTURE=1

#Update