نسخه LTS جدید برای NodeJs منتشر شد.
بزودی لیستی از ویژگی های این نسخه در اینجا خواهم گذاشت.
اگر هم دوست دارید میتونید خودتون برید بخونید.

https://nodejs.org/en/blog/release/v20.9.0

یکی از مشکلاتی که Node داشت و Deno سعی بر حل آن بود امنیت اجرای پکیج های 3rd party بود که اگر پکیجی بخواهد کارهایی از قبیل دسترسی به network یا خواندن و نوشتن دیتا روی disk انجام دهد شما باید به عنوان developer تایید کنید و اجازه دسترسی بدهید.
و حالا در Node 20 LTS شاهد این موضوع هستیم که تیم توسعه دهنده این ويژگی رو به صورت آزمایشی در Node پیاده سازی کردند که باعث امیدواری زیادی هست.

// fileread.js
import { readFileSync } from "fs";
const content = readFileSync("myfile.txt");
console.log(content);

حالا شما اگر فایل fileread.js رو اگر با کامند

node fileread.js

به صورت معمول استفاده کنید همه چیز طبق روال قدیم اجرا خواهد شد.
ولی اگر بخواهید از این ویژگی استفاده کنید حتما باید برنامه خود را با flag

--experimental-permission

اجرا کنید.

node --experimental-permission fileread.js

حالا با اجرای fileread با این flag شما با ارور زیر مواجهه خواهید شد که در بخش توضیحات ارور میگه برنامه شما در حال تلاش برای خواندن فایل از روی دیسک است و دسترسی به خواندن فایل از روی سیستم نیاز است.

node --experimental-permission fileread.js                    
node:internal/modules/cjs/loader:178
  const result = internalModuleStat(filename);
                 ^

Error: Access to this API has been restricted
    at node:internal/main/run_main_module:23:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'FileSystemRead',
  resource: '/home/imanhpr/Desktop/sandbox/nod/fileread.js'
}
Node.js v20.9.0

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

node --experimental-permission --allow-fs-read='*' fileread.js 

این ویژگی امنیت پروژه های شما رو تا حدود زیادی بالاتر میبرد و به پکیج های نصب شده توسط npm اجازه ارسال اطلاعات بدون دسترسی نمیدهد و درصورتی که پکیج مخربی نصب کنید به سرعت متوجه خواهید شد.

یکی دیگر از قابلیت های بسیار خفن Node 20 LTS که باز هم الهام گرفته از Deno هست، ایجاد Single executable applications هست. یعنی دیگر شما نیازی نیست که حتما node روی سیستم نصب داشته باشید برای اجرای برنامه های nodejs و میتونید با ایجاد یک فایل executable ( به عنوان مثال فایل های .exe در ویندوز ) برنامه خودتون رو به راحتی منتشر کنید.
البته این ویژگی نیز دوباره به صورت Experimental اومده و هنوز خیلی محدودیت هایی دارد ولی خب در آینده یکی به عنوان یک ویژگی خیلی خوب node میشه ازش نام برد. در حال حاظر فقط میتوان به صورت پیشفرض از Std خود node استفاده کرد یعنی دسترسی به پکیج های npm به صورت پیش فرض نداریم ( میتونیم اضافه کنیم و در پست های بعدی آموزشش رو حتما خواهم گذاشت)
اگر خودتون دوست دارید جزیات بیشتر رو ببینید اینجا میتونید برسی کنید.
https://nodejs.org/api/single-executable-applications.html#single-executable-applications

آموزش ویدیویی حتما راجع به این میزارم براتون.
موفق باشید همگی👍

تغییر دیگری که در NodeJs 20 LTS شاهد هستیم Stable شدن Test runner خود Node هست که بنظرم خیلی بهتر از پکیجی مثل Jest هست. البته vitest خیلی قوی عمل کرده من خودم vitest رو داخل چند پروژه استفاده کردم و واقعا قدرتمند بود. این دو پکیج رو در حال حاظر نمیتونم مقایسه کنم ولی در آینده قطعا از Test Runner خود Node در یک پروژه استفاده خواهم کرد.
اگر قصد یادگیری unit test نوشتن دارید پیشنهاد میکنم یا از vitest یا همین پکیج استفاده کنید و سمت jest نرید چون مشکلات خیلی زیادی داره و ممکنه ساعت ها اذیت کنه شما رو مخصوصا با type noscript.
به عنوان مثال فایل main.js

export function sum(input) {
  return input + 2;
}

export function minus(input) {
  return input - 2;
}

حال تست های مربوط به خودمون رو داخل فایل زیر قرار میدهیم. test/main.spec.js

import assert from "assert";
import { describe, test } from "node:test";
import { sum } from "../main.js";

describe("Check Sum Function.", () => {
  test("Sum 2 + 2 = 4", () => {
    const result = sum(2);
    assert.strictEqual(result, 4);
  });
  test("Sum 4 + 2 == 6", () => {
    const result = sum(4);
    assert.strictEqual(result, 3);
  });
});

برای اجرای تست ها میتوانید از flag

--test

استفاده کنید.

node --test

در صورتی که میخواهید Test coverage بگیرید میتوانید از flag

 --experimental-test-coverage 

استفاده کنید

node --test --experimental-test-coverage

کلا میتوان درمورد تست ساعت ها میتوان بدون وقفه صحبت کردن و نوشتن تست خوب از نوشتن اصل برنامه کار سخت تری هست. و اگر قصد مهاجرت دارید یکی از skill هایی که قطعا از شما انتظار میرود توانایی نوشتن تست های خیلی خوب میباشد.
در آینده درمورد نوشتن تست و تکنیک های unit test نوشتن قطعا صحبت خواهیم کرد.

راستی برای دیدن code snippet ها به شکل مناسب حتما تلگرام خودتون رو آپدیت کنید رفقا.

#include <iostream>

int main()
{
    std::cout << "Let The Performance Begin!\n";
    return 0;
}

به عنوان برنامه نویس BackEnd شما صرفا نباید یک framework developer باشید. باید به درجه ای برسید که بیت به بیت دیتایی که دارید کار باهاش انجام میدید رو بشمارید.
برای رسیدن به همچین سطحی که برای بهینه کردن در حد Bit و Byte صرفا فقط کد زدن و یاد گرفتن زبان و فریمورک جدید کافی نیست. باید در مسیری قدم بزاری که این روزا کمتر آدمایی قدم میزارن. یعنی باید با عینک علمی تر و حتی شاید خننده دار باشه ولی فلسفی تر نگاه کرد.

یک سری کلمات پایه ای وجود داره که نقطه شروع برای رسیدن به همچین نقطه ای هست. این کلمات رو در مطالب من زیاد خواهید دید و هرکدوم رو در تایم مناسب توضیح میدم.

کلا ذات هر سیستم نرم افزاری بسیار بسیار شکننده هست. برای این که نرم افزار ما از این شکنندگی خارج شود باید ( تاکید میکنم باید ) این نکات رو بدونیم.

یک نکته ای هم بگم که شما میتونید تا ابد یک framework developer باشید با درامد خیلی عالی در کشور های تاپ دنیا و هیجی از این نکات هم ندونید.

این فقط عطش یادگیری هست که مثل بنزین در این مسیر به شما انرژی میده که رو به جلو قدم بردارید.

یک سری از موضوعاتی که در این مورد ساعت ها خواهیم وقت گذاشت از این قبیل هستند :
- Compile time vs Runtime
- Dynamic typing vs. static typing
- Strong and weak typing
- Runtime errors vs compile time errors
- Compile time and Runtime Polymorphism
همین الان چند بار در این لیست کوتاه که تیتر وار اشاره کردم کلمه Runtime و Compile time چند بار تکرار شد که اهمیت بالای این موضوع رو نشون میده.
وقتی که بتونید کدتون رو با این عینک که چه تاثیری در Runtime یا Compiletime برنامه میتونه داشته باشه فارغ از زبان برنامه نویسی ببینید.
خودتون اون روز متوجه حرف من خواهید شد که چه تاثیری در استایل کد زدن شما خواهد داشت.

الان حضور ذهن ندارم ولی از این دسته موضوعات کم نیست و این که باهم عمیق به هرکدوم نگاه میکنیم.

دونستن این جنس نکات اعتماد به نفستون رو در مصاحبه بالا میبره و حتی میتونید شخص مصاحبه کننده رو به چالش بکشونید.

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

۱.چیست؟
۲.چرا؟


#TIP

کتاب درمورد #Golang میخوندم و این پارگراف یکی از زیباترین متن هایی بود که تا حالا دیدم.
درمورد مفهومی وارد شده از دنیای مسابقات اتومبیل رانی به دنیای نرم افزار به اسم mechanical sympathy صحبت میکنه و میگه راننده ای که دقیق با جزیات میدونه ماشینش چطور کار میکنه میتونه تا آخرین ذره قدرت ماشینش رو بکشه بیرون.
حالا شما کلمه "راننده" رو با "برنامه نویس" و ماشین رو با "زبان برنامه نویسی" یا "Runtime env" یا کلمات دیگ جایگزین کن.

و در اخر هم شخصی به اسم Martin Thompson در سال 2011 این موضوع رو سعی کرد در دنیا برنامه نویسی اجرا کنه.

اگر کجکاوی بیشتر دارید اینجا میتونید سر بزنید.

https://mechanical-sympathy.blogspot.com/

بزارید با یک خلاصه از Deno شروع کنیم.
کلا Deno هم مثل Node یک Runtime Environment هست که شما کد جاوا اسکریپت مینویسی و با استفاده از API هایی که Deno در دسترس شما قرار میده میتوانید با سیستم عامل ارتباط بگیرید.
مثل ایجاد HTTP Server یا TCP Socket یا خواندن و نوشتن فایل.

از ویژگی های مثبت Deno بخوام بگم موضوعات زیر هست.
- سرعت بالاتری که نسبت به Node داره.
- با استفاده از permission سیستمی که داره امنیت خیلی زیادی به پروژه های شما میده که Node در نسخه 20 LTS سعی کرد این ویژگی رو که از Deno الهام گرفته اجرا کنه
مثال :
شما یک فایل myfile.txt دارید که یک متن داخلش نوشته شده و میخواید از روی دیسک بخونید.

// main.ts
const result = Deno.readTextFileSync("myfile.txt");
console.log(result);

با دستور زیر اگر بخواید برنامه رو run کنید

deno run main.ts

ازتون میپرسه که آیا به برنامه اجازه خوندن فایل روی دیسک با جزیات دقیق میدی یا خیر که با وارد کردن Y همه چی اوکی میشه.

Deno requests read access to "myfile.txt".
├ Requested by `Deno.readFileSync()` API.
├ Run again with --allow-read to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) > y

حالا شاید این موضوع احمقانه بنظر برسه ولی اگر یک پکیج که یک شخص ناشناس نوشته و شما از npm نصب بکنید اگر بخواد خراب کاری کنه بهتون خبر میده و متوجه میشید و قبلا این موضوع در node خیلی مشکلات امنیتی ایجاد کرده بود.
البته حالا node هم همین ویژگی رو داره اوکی میکنه.
https://news.1rj.ru/str/NodeMaster/7
- موضوع بعدی این که به راحتی #TypeScript رو اجرا میکنه و نیازی به transpile کردن به js برای اجرا نداره و خودش مستقیم ts رو اجرا میکنه. مثل ts-node.
- نکته بعدی این که سعی بر این شده که از Web api های استاندارد برای interface شدن با api های سیستم عامل استفاده بشه که این میتونه مزیت خوبی باشه به این دلیل که اگر web api های js رو بلد باشین اینجا نیازی نیست چیز جدیدی یاد بگیرید.
- موضوع بعدی این که از پکیج های npm هم میتوانید داخل deno استفاده کنید. پکیج های npm که برای node توسعه داده شدند سرعت کمتری نسبت به پکیج های native خود deno دارند و این که مشکلاتی هم از نظر سازاگاری هست. درکل در بهترین حالت این هست که برنامتون کامل از api های deno استفاده کنه.
- به راحتی میتونید از برنامتون خروجی Single executable بگیرید با دستور و روی هر پلتفرمی اجرا کنید.

deno compile main.ts

به عنوان مثال یک http web server در deno
```json

{
  "name": "Node Master",
  "author": "imanhpr"
}
```

```javanoscript
import user from "./user.json" with {type : "json"};

Deno.serve({port : 3005} , (req) => {
  return new Response(JSON.stringify(user))
})

```
به این تکه کد شما یک http server برای پروداکشن دارید با پرفرومنس بالا.

از نکات منفی Deno بخوام بگم
- کامینیوتی کوچک
- پکیج های 3rd party کم
- کمبود منابع آموزشی.
در کل Deno برای با تجربه تر ها خوبه و برای تازه کار خوب نیست بازار کارش مشخص نیست و صرفا به عنوان سرگرمی باید بهش نگاه کرد هرچند پتانسیل خوبی داره و اینجا لیست کوچیکی از ویژگی هاش رو گفتم.
باهاش چنتا برنامه سعی میکنیم بنویسم و یکم نگاهی بهش بندازیم.

مفهوم CPS Style چیست و در NodeJs به چه صورت هست؟
خب دوستان همین الان بگم که خیلی از افرادی که با Node کار کردن تمام مدت از این استایل استفاده کردن حتی بدون این که اسمش رو بدونن.
بزارید با مثال و کد توضیح بدم خیلی راحت متوجه میشید.

function doSomething() {
  return "Something important"
}

در این کد خیلی ساده وقتی ما به صورت مستقیم یک مقداری رو مستقیم return میکنیم به این میگن Direct Style یا استایل مستقیم.
حالا بریم سراغ CPS که در زبان های فانکشنال خیلی مرسوم هست و در Node هم این استایل زیاد دیده میشه مخصوصا api های قدیمی Callback base async

function doSomething(done) {
  done("Something important");
}

function print(str) {
  console.log(str);
}

doSomething(print);

در این برنامه ساده ما یک فاکشن داریم به اسم doSomething که یک فانکشن رو به عنوان رفرنس ورودی میگیره و بعد بجا return کردن خروجی نتیجه رو به عنوان arg با فانکشن done کال میکنه.
فانکشن print هم یک متن ورودی میگیره و صرفا لاگ میکنه
این همون callback عادی خودمون هست ولی خب با عینک علمی تر یک پترنی هست به اسم cps style که گاهی پیش میاد کلی callback تو در تو داشته باشیم.
بد بودن یا خوب بودن این موضوع در اینجا مهم نیست چون بحث سر این زیاده داخل Node.

خودتون قطعا این مورد رو میدونید ولی من میخواستم شما رو با استایل و پترنش آشنا کنم چون در یکی دو پست آینده چنتا کد میخوام معرفی کنم و این مقدمه اونا هست.

در حال حاظر NodeJs برای هرکاری 3 API گاهی هم 2 API در دسترس شما قرار میده تا کارتون رو انجام بدید.
به مثال زیر دقت کنید.

import { readFile as readFileCps, readFileSync } from "node:fs";
import { readFile as readFilePromise } from "node:fs/promises";

// Sync api - Direct style.
const syncRead = readFileSync("myfile.txt", "utf-8");
console.log("1.", syncRead);

// Async api - CPS style.
readFileCps("myfile.txt", "utf-8", (err, data) => {
  if (err) process.exit(1);
  console.log("2.", data);
});

// Async Promise api - looks like sync style - await syntax
const asyncRead = await readFilePromise("myfile.txt", "utf-8");
console.log("3.", asyncRead);

// Async Promise api - looks like CPS style.
readFilePromise("myfile.txt", "utf-8").then((data) => console.log("4.", data));

کلا دقیقا داریم یک کار میکنیم خوندن فایل با استایل های مختلف که خود Node بهمون داده.
اولی به صورت Direct style هست و این عملیات Sync هست و یجاهایی مثلا برای load کردن config فایل کاربرد داره و به هیچ عنوان در http server این رو استفاده نکنید مگر این که دقیق میدونید کجا استفاده کنید.

دومین api که node به ما میده async از طریق cps استایل که node تضمین میکنه به صورت async کد شما اجرا میشه و اصولا async cps syle جز api های قدیمی async در node هستن. قبل از این که promise بیاد همیشه از اینا استفاده میشد.

سومی و چهارمی دقیقا یک شکل هستن اون پشت فقط ظاهرشون فرق میکنه و در خوانایی کد تاثیر داره و گاهی در شرایط خاص فقط از یکیشون میشه استفاده کرد.
هردو جز api های async در node هستن که با promise ها کار میکنند. از وقتی که Promise api ها وارد node شدن CPS style کمرنگ تر شد.

تمام این قصه ها رو گفتم تا برسم به اینجا که.
هنوز هم کد هایی در NodeJs وجود داره که CPS style هستند و معادل Promise API ندارند.
گاهی شما برای کارتون نیاز دارید که این CPS Style ها رو تبدیل کنید به Promise Api و حتی گاهی برعکس.
برای همین میخوام بهتون یک تکنیک نشون بدم با مثال کاربردی که چطور این کار رو انجام بدیم.
در این مدت هم اگر دوست داشتید فکر کنید ببینید خودتون میتونید چیزی پیدا کنید؟

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

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

خب پیرو سوالی که در اینجا گفتم امیدوارم خودتون اگر کنجکاوی کردین به نتیجه رسیده باشید.
در کتاب خانه

node:util

دوتا فانکشن وجود داره به اسم callbackify و promisify که کار این دو فانکشن این هست که CPS style رو تبدیل میکنه به Promise api و برعکس و نحوه کار کرد این دوتا رو الان میبینیم

import { callbackify } from "node:util";

// Promise to CPS
async function myJob() {
  return "this is a result";
}

const cpsMyJob = callbackify(myJob);
cpsMyJob((err, result) => console.log("in cps :", result));

در این مثال ما یک فانکشن async داریم که خب همیشه یک Promise به ما میده و مشخصه. حالا جایی نیاز داریم که این رو تبدیل کنیم به CPS Style و با استفاده از فانکشن callbackify میتونیم نسخه CPS رو بسازیم.
توجه کنید که این نسخه طبق قرارداد کد های node اولین پارامتر رو err میزاره و شما باید در کد های پروداکشن این بخش رو حتما هندل کنید.

import { promisify } from "node:util";

// CPS to Promise
function myJobSync(done) {
  return done(null, "this is a result");
}

const myJob = promisify(myJobSync);
console.log(await myJob());

و حالا اینجا ما یک فانکشن CPS style داریم که اومدیم اون رو با استفاده از promisify تبدیل کردیم و بعد نتیجه رو await کردیم و خب همه چی درست کار میکنه.

نکته خیلی خیلی مهم :‌ هر فانکشنی که Callback میگیره لزوما Async نیست دوستان. یعنی myJobSync درسته داره callback میگیره ولی عملیات داخلش به صورت sync هست و یعنی ما اگر از direct style استفاده کنیم منطقی تره ولی خب اینجا برا آموزش بود. برای async کردن کلا یک فرایند دیگ طی میشه که بعدا درمورد event loop که خواستیم صحبت کنیم حتما میگیم.

شما حتی میتونید کتاب خونه های استاندارد هم با این کار تبدیل کنید و استفاده اصلی این دوتا دقیقا اونجا هست

import { randomBytes } from "node:crypto";
import { promisify } from "node:util";

const _randomByte = promisify(randomBytes);
console.log(await _randomByte(5));

به عنوان مثال کتاب خونه node:crypto اکثرا api ها از حالت CPS style استفاده میکنن و خیلی نیاز میشه که اون ها رو بخوایم تبدیل کنیم به Promise که بتونیم await کنیم. و شما الان با این تکنیک راحت میتونید این کار انجام بدید.

در پست بعدی یک مثال خیلی کاربردی با هم میبریم جلو که میتونید داخل پروژه هاتون استفاده کنید و تمرین خوبی هم حتی هست برای عمیق تر شدن در NodeJS

آیا این فانکشن async هست یا خیر.

function myJob(done){
    retrun done(null, "result");
}

مدتی هست از Bun به عنوان package manager دارم استفاده میکنم روی پروژه ها.
به صورت کلی سرعت خیلی خوبی داره ولی چندین بار به یکسری مشکلات خوردم که واقعا اذیتم کردن.

یه تایم دیگ درمورد مشکلات با جزیات بیشتری پست میزارم ولی اگر قصد دارید برای پروژه جدی ازش استفاده کنید پیشنهاد من همون yarn و npm هست در حال حاظر.

معمولا وقتی در حال پیاده سازی Password Auth در Backend برا خودمون هستیم برای امنیت که در صورت leak شدن database پسورد ها رو به صورت Hash ذخیره میکنیم. ۳ الگوریتم پر استفاده برای hash کردن پسورد ها وجود داره به نام های Bcrypt , Scrypt و Argon2 که مرسوم ترین این الگوریتم ها در Nodejs الگوریتم bcrypt هست. در این پست به جزیات تفاوت این الگوریتم ها کاری نداریم که کدوم بهتر از دیگری هست.
نکته ای که اینجا هست این هست که Nodejs اکثر پیاده سازی های bcrypt در nodejs با JS هست که خب صدرصد کند تر از کد CPP هست.
در کتاب خانه node:crypto پیاده سازی native برای scrypt وجود داره که میتونید راحت ازش استفاده کنید. و چون با CPP پیاده سازی شده قطعا performance بهتری داره.
البته اینجا بحث امنیت رو نظر نمیگیرم و فقط راجع به performace داریم صحبت میکنیم و ممکنه با توجه به شرایط امنیتی مختلف شما مجبور باشید که از یکی از اینا اجبارا استفاده کنید.

import { scryptSync } from "node:crypto";

const myPassword = "RawP@sword";
const mySalt = "salt";
const hashedPassword = scryptSync(myPassword, mySalt, 64);
console.log(hashedPassword);

در پایه ای ترین حالت از شما پسورد خام و یک salt رو میگیره و با توجه به ترکیب اینها یک Buffer به شما میده که حالا میتونید با فرمت های مختلف مثل hex یا base64 سریالایز و ذخیره کنید.
پارامتر سوم هم keylen هست که حداقل مقدار طبق best practise ها 64 byte هست که هرچقد بالاتر باشه درصد کرک کردن پسورد سخت تره
(سعی کنید بیشتر از 512 نزارید چون برای generate و validate کردن هزینه زیادی رو سرور داره).

و این که در این مثال از نسخه Sync استفاده شده و شما حتما باید از async api برای کد پروداکشن استفاده کنید.
نکته بعد این که فقط به صورت CPS async style ارایه شده و حتما باید از promisify استفاده کنید در صورتی که نیاز به Promise دارد.
در پست بعدی راجع به best practise های استفاده از این توضیح خواهم داد ولی یک سوال دارم از شما و یک چلنج.
۱. دلیل استفاده از salt چی هست؟ اصلا salt چی هست؟ (کامنت بزارید زیر پست)

و اما چلنج :‌ معمولا کتاب خونه های ارایه شده برای پسورد خودشون عملیات serialize کردن و validation رو انجام میدن.
اما اینجا تمام این کارا رو باید خودتون دستی انجام بدید و فقط از این api براای secure کردن پسورد استفاده کنید.
میخوام بگم که سعی کنید خودتون یک hashing password class به همراه validator پیاده سازی کنید چلنج های باحالی داره این کار و خیلی چیزا یاد میگیرید.

همونطور که اکثریت این رو درست گفتن پس فکر کنم نیازی به توضیح نداره.

دوتا از پرکاربرد ترین و مهم ترین event های در NodeJS که خیلی کم توجهی بهش شده "uncaughtException" و "unhandledRejection " میباشد که پیشنهاد میکنم اگر برنامه ای روی production دارید حتما این دو رو اضاف کنید.
بخاطر ذات dynamic type و duck type بودن JS و این که شما تا زمان Runtime خبر نداری که یک object چی داخلش هست و Null pointer خیلی مرسوم هست داخل JS و البته ذات async NodeJS تمام این نکات دست به دست هم داده تا یک مشکل خیلی جدی داشته باشیم برای هندل کردن Error هایی که کمتر به چشم میاد و در نظر نمیگیرم.
یعنی ممکنه یک جایی از برنامه احتمال وجود خطایی باشه که اتفاق میافته هیچ لاجیک برای catch کردن نداره و process کرش میکنه و سرویس شما down میشه. صحبت بسته بزارید با کد روشن تر کنم قضیه رو براتون.

async function jobLogicAsync(input) {
  // Some work
  return JSON.parse(input);
}

async function main() {
  // Invalid input at runtime
  const result = await jobLogicAsync("{");
}
main();

اینجا همه چی درست کار میکنه و هیچ مشکلی نیست و یکی از نقد های js این هست که همچین ارور هایی به راحتی به چشم نمیاد. فرض کنید یک
فانکشن داریم یک کاری انجام میده به صورت async با نام jobLogicAsync. همینطور که میبینید هیچ logic ارور هندلینگ وجود نداره و این ارور در بهترین حالت
برنامه ما رو باید crash کنه ( توجه کنید در بهترین حالت این کار باید کنه ) درصورتی که ممکنه یک سری side effect های خطرناک مثل ایجاد corrupt data بشه و
زیان زیادی رو وارد کنه.
تو این مثال هم همه چی درست کار میکنه اگر ما json string درست باشه اما خب کسی خبر نداره از runtime که!
در این شرایط باید راهی پیدا بشه که ما خبر دار بشیم همچین اروری رخ داده به صورت log که بعد trace کنیم و مشکل رو پیدا کنیم. اینجاس که اون دو event به داد ما میرسن.

process.on("unhandledRejection", (err, orgin) => {
  console.error("error : ", err);
  console.log("origin : ", orgin);
  process.exit(1);
});

process.on("uncaughtException", (err, origin) => {
  console.error("error : ", err);
  console.log("origin : ", orgin);
  process.exit(1);
});

این دو event بر روی process global object رخ میدن. و باید روی process.on ما اینا رو دریافت کنیم و در هنگام اجرا پروژه قبل از هرچیزی اینا رو listen کنیم.
کار این دو event به این صورت هست.
1. uncaughtException گرفتن ارور هایی که از sync routine ها هستن
2. unhandledRejection گفرتن promise هایی که reject شدن که .catch نداشتن

به دلیل این که ممکنه هر هرکجایی از یک سیستم چند هزار خطی این ارور ها اتفاق بیوفته شرایط هندل کردن این ارور ها یکم سخت هست به خاطر همین best practise این هست که در صورت اتفاق افتادن این ارور ها اون ها رو لاگ کنیم
و process رو با کد غیر 1 ببندیم و developer رو خبر دار کنیم که مشکل غیر منتظره ای در حالت خاصی رخ داده برسی کن.
میتونید process رو kill نکنید ولی خطر side effect ها رو در پروژه های بزرگ جدی بگیرید.

خیلی میتونیم رو این موضوع عمیق تر بشیم ولی خب فعلا در همین حد بنظرم کافی هست تا زیاد طولانی نشه و یک روزی در ویدیو بیشتر این موضوع رو توضیح میدیم.
البته توضیح خیلی میتونه علمی تر و دقیق تر در سطح node engine باشه ولی خب بنظرم همینقدر برای شروع کافیه.