10 اشتباه رایج توسعه‌ دهندگان Nodejs و راه حل آن‌ ها

10 اشتباه رایج توسعه‌ دهندگان Nodejs و راه حل آن‌ ها

Nodejs که در سال های اخیر به یکی از محبوب ترین فناوری های توسعه بک اند تبدیل شده امروزه تقریبا در تمام پروژه های بزرگ ردپایی از آن دیده می شود! از API های ساده و سرویس های کوچک بگیرید تا سیستم های بزرگ برای شرکت های بزرگ!

سرعت توسعه بالا در کنار معماری غیر همزمان٬ و کتابخانه های گسترده NPM در کنار امکان استفاده از جاوا اسکریپت در سمت سرور باعث شده این محبوبیت هر روز بیشتر از قبل شود! و امروزه استارتاپ ها و شرکت های بزرگ برای توسعه بک اند در کنار گزینه های دیگر از آن استفاده می کنند!

اما یک نکته را که باید همیشه در نظر داشته باشید این است که صرفا انتخاب Nodejs به تنهایی تضمین نمی کند که قرار است پروژه ای که توسعه می دهد موفق باشد! موفقیت در یک پروژه به موارد زیادی بستگی دارد که مهم ترین آن ها نحوه پیاده سازی و تصمیماتی هست که در حین توسعه گرفته می شود!

خیلی از مشکلاتی که در پروژه های واقعی دیده می شود به این خاطر ضعف ذاتی نود جی اس نیست بلکه رعایت نکردن برخی اصول مهم و تکرار اشتباهاتی هست که بار ها توسط توسعه دهندگان دیگر انجام شده است!

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

اجازه دهید قبل از اینکه به بررسی این اشتباهات برسیم به دو موضوع مهم دیگر اشاره کنیم! دو موضوعی که تقریبا روی تمام بخش های پروژه نود جی اس تاثیر مستقیم دارد: عملکرد و امنیت!

یکی از چالش های مهمی که توسعه دهندگان در زمان ورود پروژه به مرحله پروداکشن با آن مواجه می شوند این است که عملکرد و امنیت پروژه به چه صورت هست!

وقتی یک پروژه در مراحل اولیه انتشار هست بخاطر اینکه کاربران محدودی وارد آن می شوند بدون مشکل کار می کنند اما وقتی تعداد درخواست ها افزایش پیدا می کند و حجم داده ها بالا می رود و کاربران سیستم رشد می کنند تازه مشکلات خودش را نمایش می دهد! مشکلاتی نظیر افزایش مصرف حافظه٬ کاهش سرعت پاسخ دهی٬ فشار بیش از حد روی CPU و افت کارایی سیستم تنها بخشی از مشکلات احتمالی می باشد! تمام این موارد را می توان به شکل اصولی و با رعایت برخی اصول و تکنیک های بهینه سازی بهبود ببخشید و عملکرد برنامه را دوباره به حالت ایده آل بازگرداند!

اگر قصد دارید درباره روش های افزایش سرعت و بهینه سازی نود جی اس بیشتر بدانید و از آن استفاده کنید! ما قبلا مقاله را با عنوان 17 تکنیک حرفه ای برای افزایش سرعت NodeJS منتشر کردیم که می توانید مطالعه بفرمایید.

در این مقاله به روش‌ های مختلفی برای بهبود کارایی برنامه‌ ها پرداخته‌ ایم و نکاتی را بررسی کرده‌ ایم که می‌ توانند تاثیر قابل توجهی بر عملکرد و مقیاس‌ پذیری پروژه‌ های Nodejs داشته باشند.

در کنار عملکرد که خدمت شما توضیح داده شد بخش دیگر که باید به آن اهمیت ویژه داده شود بحث امنیت می باشد! متاسفانه بسیاری از توسعه دهندگان تا زمان مواجه نشدن با یک مشکل امنیتی هیچ توجهی به این مولفه ندارند! در حالی که بسیاری از حملات سایبری٬ سو استفاده از آسیب پذیری ها و نشت اطلاعات حساس بخاطر سهل انگاری های ابتدایی مراحل توسعه می باشد که می توان به شکل ساده از آن جلوگیری کرد!

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

به همین دلیل، پیش از ورود به مباحث اصلی این مقاله که همان اشتباهات رایج توسعه دهندگان نود جی اس می باشد پیشنهاد می‌کنیم مقاله امنیت NodeJs از صفر تا صد! به همراه 10 آسیب‌ پذیری خطرناک ٔNodeJS ! را نیز مطالعه کنید.

در این مقاله مهم‌ ترین تهدید های امنیتی و راهکارهای مقابله با آن‌ ها را بررسی کرده‌ ایم تا بتوانید برنامه‌ های امن‌ تر و قابل اعتماد تری توسعه دهید.

اما نکته اصلی بحث این مقاله! اینجاست که حتی اگر عملکرد و امنیت را در زمان توسعه رعایت کرده باشید باز هم موضوعات دیگری وجود دارند نباید از آن ها غافل شد! اشتباهات رایجی که از توسعه دهندگان مبتدی این پلتفرم تا برنامه نویسان باتجربه ناخواسته مرتکب آن می شوند!

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

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

در ادامه این مقاله، به سراغ 10 اشتباه رایج توسعه‌ دهندگان Nodejs می‌ رویم! اشتباهاتی که بارها در پروژه‌ های واقعی مشاهده شده‌ اند و برای هر کدام، راهکار هایی عملی و کاربردی ارائه خواهیم کرد تا بتوانید برنامه‌ هایی سریع‌ تر٬ پایدار تر و امن‌ تر توسعه دهید.

آیا مشکلات پروژه‌ های Nodejs واقعا از ذات خود پلتفرم هستند؟

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

به عبارت دیگر، Nodejs تنها یک ابزار است و کیفیت خروجی نهایی تا حد زیادی به تصمیم‌ هایی بستگی دارد که در طول توسعه گرفته می‌ شوند.

وقتی صحبت از مشکلاتی مانند افت عملکرد، افزایش مصرف حافظه، پیچیدگی بیش از حد کدها یا حتی بروز خطا های غیر منتظره در پروژه‌ های Nodejs می‌ شود، بسیاری از توسعه‌ دهندگان در نگاه اول تصور می‌ کنند که ریشه این مشکلات به خود نود جی اس باز می‌ گردد. در حالی که در اغلب موارد، مشکل از پلتفرم مورد استفاده نیست، بلکه از نحوه استفاده از آن ناشی می‌ شود.

این نکته را در نظر داشته باشید که نود جی اس یک محیط اجرایی هست که طی سال های گذشته در انواع پروژه ها و API ها و سیستم های بزرگ و کوچک و حتی پرترافیک مورد استفاده قرار گرفته و امتحان خود را پس داده است! پس چالش هایی که توسعه دهنده در مسیر با آن مواجه می شود بخاطر اشتباه در تصمیمات و معماری نامناسب و رعایت نکردن برخی اصول ساده توسعه هست نه اینکه ذاتا نود جی اس دچار مشکل باشد!

نکته مهم اینجاست که بیشتر این مشکلات، از اشتباهاتی سرچشمه می‌ گیرند که بارها و بارها توسط توسعه‌ دهندگان مختلف تکرار شده‌ اند. اشتباهاتی که شاید در پروژه‌ های کوچک تأثیر چندانی نداشته باشند، اما در محیط Production و در مقیاس‌ های بزرگ می‌ توانند باعث افت عملکرد، افزایش تعداد باگ‌ ها، دشوار شدن توسعه قابلیت‌ های جدید و حتی ایجاد مشکلات امنیتی شوند.

از طرف دیگر، Nodejs به دلیل ماهیت غیرهمزمان و Event-Driven خود، تفاوت‌ های مهمی با بسیاری از پلتفرم‌ های دیگر دارد. همین تفاوت‌ ها باعث می‌ شود برخی الگوها و روش‌ هایی که در سایر زبان‌ ها یا فریم‌ ورک‌ ها مشکلی ایجاد نمی‌کنند، در نود جی اس به نقاط ضعف جدی تبدیل شوند. برای مثال، اجرای پردازش‌ های سنگین روی Thread اصلی، مدیریت نادرست خطا ها، استفاده بیش از حد از Callback ها، اعتبارسنجی نکردن داده‌ های ورودی یا نگهداری اطلاعات حساس داخل کد، از جمله اشتباهاتی هستند که می‌ توانند کیفیت نهایی پروژه را تحت تاثیر قرار دهند.

در ادامه، به سراغ 10 اشتباه رایجی می‌ رویم که بسیاری از توسعه‌ دهندگان Nodejs با آن رو به رو می شود!

10 اشتباه رایج توسعه‌ دهندگان:

در ادامه به 10 مورد از اشتباهات رایجی می پردازیم که در پروژه های مختلف بارها شاهد آن بودیم! جلوگیری از این اشتباهات و عادت به کدنویسی صحیح و اصولی می تواند فرآیند توسعه را کاملا هدفمند تر کند و پروژه نهایی با کیفیت بالاتری انتشار یابد و با افزایش تعداد کاربران و بالا رفتن تعداد درخواست ها مشکل خاصی برای پروژه ایجاد نشود!

1- استفاده بیش از حد از Callback ها:

یکی از مشکلاتی که تقریبا تمام توسعه دهندگان قدیمی نود جی اس حداقل یک بار هم که شده با آن رو به رو شدند استفاده بیش از حد از Callback ها و ایجاد چیزی است که به آن اصطلاحا Callback Hell گفته می شود!

اگر چه کال بک آپ ها بخشی مهمی از معماری غیرهمزمان Nodejs هستند اما اگر به شکل نادرست مورد استفاده قرار بگیرند به مرور زمان کدها را پیچیده تر٬ ناخواناتر و نگهداری را دشوار تر می کند!

در نسخه‌ های اولیه Nodejs، Callback ها رایج‌ ترین روش برای مدیریت عملیات غیرهمزمان بودند. خواندن فایل‌ ها، برقراری ارتباط با پایگاه داده، ارسال درخواست‌ های HTTP و بسیاری از عملیات دیگر از طریق Callback انجام می‌ شدند.

این روش در پروژه های کوچک مشکلی ایجاد نمی کرد اما وقتی که چندین عملیات غیرهمزمان به یکدیگر وابسته باشند ساختار کد به سرعت پیچیده می شود!

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

به‌ رو خواهید شد:

fs.readFile("file.txt", (err, data) => {

  if (err) throw err;

  db.findUser(data, (err, user) => {

    if (err) throw err;

    sendEmail(user, (err) => {

      if (err) throw err;

      console.log("Done");

    });

  });

});

وقتی به این کد نگاه می کنیم شاید ساده به نظر برسد اما با بزرگتر شدن پروژه و افزایش تعداد عملیات های غیرهمزمان٬ این کال بک آپ ها تو در تو می شوند و کد ها به ساختاری پیچیده و غیرقابل مدیریت تبدیل می شوند!

همین موضوع سبب شده است که Callback Hell در نود جی اس شکل بگیرد!

یکی از بزرگترین مشکلات این Callback Hell ها کاهش خوانایی کد است! توسعه دهندگان در زمان دیباگ کردن یا اضافه کردن قابلیت های جدید مجبور هستند بین چندین سطح تو در تو جابه جا شوند این مورد احتمال بروز خطا را افزایش می دهد!

علاوه بر این، مدیریت خطا ها نیز دشوارتر می‌ شود. در ساختار مبتنی بر Callback، معمولا در هر مرحله باید خطا ها به صورت جداگانه بررسی شوند که این موضوع باعث تکرار کد ها و کاهش خوانایی برنامه خواهد شد.

راه حل چیست؟

امروزه استفاده از Promise ها و Async/Await بهترین روش برای مدیریت عملیات غیر همزمان در Nodejs محسوب می‌ شود. این روش باعث می‌ شود کدها ساختاری شبیه کدهای همزمان پیدا کنند و در عین حال مزایای برنامه‌ نویسی غیرهمزمان حفظ شود.

همان مثال بالا را می‌ توان به شکل زیر بازنویسی کرد:

async function process() {

  try {

    const data = await fs.promises.readFile("file.txt");

    const user = await db.findUser(data);

    await sendEmail(user);

    console.log("Done");

  } catch (error) {

    console.error(error);

  }

}

در این ساختار، جریان اجرای برنامه بسیار واضح‌ تر است و مدیریت خطاها نیز تنها در یک بلوک try/catch انجام می‌ شود. این موضوع باعث می‌شود نگهداری و توسعه کدها بسیار ساده‌ تر شود.

علاوه بر افزایش خوانایی، استفاده از Async/Await مزایای دیگری نیز دارد:

مدیریت خطاها ساده‌ تر می‌شود.

کدها تمیزتر و قابل فهم‌ تر خواهند بود.

دیباگ کردن برنامه آسان‌ تر می‌شود.

توسعه قابلیت‌ های جدید با پیچیدگی کمتری انجام می‌ شود.

احتمال بروز باگ کاهش پیدا می‌کند.

نگهداری پروژه در بلند مدت ساده‌ تر خواهد بود.

البته این موضوع به معنای حذف کامل Callback ها نیست! بسیاری از API های داخلی نود جی اس همچنان مبتنی بر کال بک آپ ها می باشند و در برخی سناریو ها هم کاملا استفاده از آن منطقی هست اما در پروژه های جدید و مدرن بهتر است تا حد امکان از Promise ها و Async/Await استفاده شود و از ایجاد ساختار های تو در تو و پیچیده جلوگیری شود!

به طور کلی، اگر هنگام مشاهده کد های خود با چندین سطح Callback تو در تو مواجه شدید، احتمالا زمان آن رسیده است که ساختار برنامه را بازبینی کنید. چرا که Callback Hell نه تنها خوانایی پروژه را کاهش می‌ دهد، بلکه در بلند مدت به یکی از عوامل اصلی افزایش پیچیدگی و دشواری نگهداری کد تبدیل خواهد شد.

2- مسدود کردن Event Loop با پردازش‌ های سنگین:

ما قبلا در مقاله ای تحت عنوان Event Loop چیست و چرا Nodejs هنگ نمی کند! در خصوص Event Loop و ويژگی های فوق العاده ای که دارد صحبت کردیم!

Event Loop در ساده‌ ترین تعریف یک حلقه بی‌ وقفه تصمیم‌ گیری است! این حلقه نه خود عملیات سنگین انجام می‌ دهد، نه منتظر می‌ ماند! بلکه کارش این است که ببیند چه چیزی آماده اجراست و در چه زمانی باید اجرا شود. این ویژگی تا زمانی که بدون مشکل در حال انجام کار باشد به درخواست های بالا به سادگی پاسخ می دهد.

اما یکی از اشتباهات  رایجی که بسیاری از توسعه دهندگان نود جی اس مرتکب آن می شوند اجرای پردازش های سنگین روی Thread اصلی برنامه هست! این موضوع در پروژه های کوچک و تازه راه اندازی شده شاید چندان محسوس نباشد اما با افزایش تعداد کاربران و درخواست ها می تواند به یکی از مهم ترین عوامل کاهش عملکرد و افت سرعت برنامه تبدیل شود!

برای درک بهتر این موضوع، ابتدا باید بدانیم که Nodejs بر پایه معماری Event-Driven و Non-Blocking I/O طراحی شده است. برخلاف بسیاری از زبان‌ ها که برای هر درخواست یک Thread مجزا ایجاد می‌ کنند، نود جی اس عمدتا از یک Thread اصلی و Event Loop استفاده می‌ کند تا بتواند تعداد زیادی درخواست را به صورت همزمان مدیریت کند.

این معماری باعث شده Nodejs برای توسعه API ها، برنامه‌ های Real-Time و سرویس‌ های پرترافیک عملکرد بسیار خوبی داشته باشد. اما همین ویژگی یک نکته مهم را نیز به همراه دارد! اگر یک عملیات سنگین روی Thread اصلی اجرا شود، Event Loop تا پایان آن عملیات درگیر می‌ شود و سایر درخواست‌ ها باید منتظر بمانند.

به عنوان مثال، تصور کنید در یکی از Endpoint های برنامه خود، پردازش سنگینی مانند فشرده‌ سازی فایل، پردازش تصویر، رمزنگاری، محاسبات پیچیده یا اجرای یک حلقه بزرگ انجام می‌ دهید:

for (let i = 0; i < 10000000000; i++) {
  // Heavy Task
}

تا زمانی که این حلقه به پایان نرسد، Event Loop قادر به پردازش درخواست‌ های جدید نخواهد بود. در نتیجه کاربران با افزایش زمان پاسخ‌ دهی، کند شدن برنامه و حتی Timeout شدن درخواست‌ ها مواجه خواهند شد.

مشکل زمانی جدی‌ تر می‌ شود که برنامه وارد محیط Production شود. ممکن است در زمان توسعه همه چیز به درستی کار کند، اما با افزایش تعداد کاربران، همین پردازش‌ های سنگین باعث شوند کل سرویس تحت تاثیر قرار بگیرد و تجربه کاربری نامناسبی ایجاد شود.

راه حل چیست؟

به طور کلی باید این نکته را همیشه در ذهن خود داشته باشید که Event Loop باید تا حد امکان آزاد بماند و فقط مدیریت درخواست ها و عملیات های I/O را انجام دهد و پردازش های CPU محور را به بخش های جداگانه منتقل کرد!

برای این کار می‌ توانید از روش‌ های زیر استفاده کنید:

Worker Threads برای اجرای پردازش‌ های سنگین در Thread های مجزا

Queue ها مانند BullMQ برای پردازش وظایف در پس‌ زمینه

استفاده از Redis Queue

انتقال پردازش‌ های سنگین به Microservice های جداگانه

استفاده از Cron Job ها برای وظایف زمان‌ بندی‌ شده

به عنوان مثال، Worker Threads امکان اجرای پردازش‌ های CPU محور را بدون مسدود کردن Event Loop فراهم می‌ کنند:

const { Worker } = require("worker_threads");

اگر برنامه شما نیاز به پردازش تصویر، تولید گزارش‌ های سنگین، رمزنگاری، تبدیل فایل‌ ها یا انجام محاسبات پیچیده دارد، استفاده از Worker Thread ها یا معماری مبتنی بر Queue می‌ تواند تاثیر قابل توجهی بر عملکرد و مقیاس‌ پذیری سیستم داشته باشد.

بنابراین این نکته را همیشه در توسعه خود مدنظر داشته باشید که نباید Event Loop را با عملیات های سنگین مسدود کنید! بسیاری از مشکلات مربوط به افت سرعت و عدم پاسخگویی سریع پروژه همزمان با رشد پروژه از همین اشتباه به ظاهر کوچک ولی تاثیرگذار ناشی می شود!

3- مدیریت نادرست خطاها و Exception ها:

یکی دیگر از اشتباهات رایجی که در بسیاری از پروژه های نود جی اس مشاهده می شود و توسعه دهندگان توجه زیادی به آن نمی کنند بحث مدیریت خطاها یا همان Error Handling می باشد! درست است که در نگاه اول این موضوع شاید خیلی مهم نباشد! اما در عمل بخش زیادی از مشکلاتی که در محیط پروداکشن رخ می دهد به دلیل مدیریت نامناسب خطا ها و Exception ها می باشد!

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

وقتی شرایط عادی باشد پروژه به درستی کار می کند و هیچ مشکلی نیست! اما به محض بروز یک خطای غیرمنتظره٬ پروژه رفتار های نامشخصی از خود نشان می دهد! گاهی درخواست ها بدون پاسخ باقی می ماند و گاهی م سرور با خطای 500 رو به رو می شود و در برخی موارد حتی کل برنامه کرش می کند و از دسترس خارج می شود!

به عنوان مثال، یکی از رایج‌ ترین اشتباهات، عدم مدیریت خطا در توابع Async است:

app.get("/users", async (req, res) => {

  const users = await User.find();

  res.json(users);

});

در ظاهر این کد مشکلی ندارد، اما اگر اتصال به پایگاه داده قطع شود یا Query با خطا مواجه شود، Exception ایجاد شده مدیریت نخواهد شد و ممکن است باعث بروز مشکلات جدی در برنامه شود.

به همین دلیل، تمام عملیات غیرهمزمان باید در بلوک‌ های try/catch قرار بگیرند:

app.get("/users", async (req, res) => {

  try {

    const users = await User.find();

    res.json(users);

  } catch (error) {

    res.status(500).json({
      message: error.message
    });

  }

});

البته استفاده از try/catch به تنهایی برای پروژه‌ های بزرگ کافی نیست. اگر در هر Controller بخواهید مدیریت خطا را به صورت جداگانه انجام دهید، کدها به مرور زمان تکراری و پیچیده خواهند شد.

به همین دلیل، یکی از بهترین راهکارها استفاده از Middleware مرکزی برای مدیریت خطاها است. در این روش، تمام Exception ها در یک نقطه مدیریت می‌ شوند و پاسخ‌ های استاندارد و یکپارچه به کاربر ارسال می‌ شود.

به عنوان مثال:

app.use(errorHandler);

این روش علاوه بر افزایش خوانایی کد، باعث می‌ شود تغییر ساختار پاسخ‌ ها یا ثبت خطا ها بسیار ساده‌ تر شود.

یکی دیگر از اشتباهات رایج، استفاده از throw error بدون مدیریت مناسب است. در برخی شرایط، یک Exception مدیریت نشده می‌ تواند باعث متوقف شدن کل فرآیند Nodejs شود.

به همین دلیل، در برنامه‌ های Production معمولاً از Global Error Handler برای مدیریت خطاهای غیرمنتظره استفاده می‌ شود:

process.on("uncaughtException", handler);

process.on("unhandledRejection", handler);

البته این مکانیزم‌ ها نباید جایگزین Error Handling صحیح در سطح برنامه شوند و بیشتر به عنوان آخرین خط دفاعی در نظر گرفته می‌ شوند.

علاوه بر این، یکی دیگر از اشتباهات رایج، نمایش جزئیات کامل خطا به کاربر است. برای مثال:

res.json(error);

این کار می‌ تواند اطلاعات حساسی مانند Query ها، مسیر فایل‌ ها و ساختار داخلی برنامه را در اختیار مهاجمان قرار دهد. در محیط Production بهتر است فقط پیام‌ های عمومی به کاربر نمایش داده شوند و جزئیات کامل خطا در سیستم های لاگ ذخیره شوند تا فقط توسعه دهنده بتواند آن را بررسی کند!

در نهایت، باید توجه داشت که مدیریت خطا صرفا به جلوگیری از Crash شدن برنامه محدود نمی‌ شود. Error Handling مناسب باعث می‌ شود:

برنامه پایدارتر باشد.

عیب‌ یابی ساده‌ تر شود.

خطا ها سریع‌ تر شناسایی شوند.

تجربه کاربری بهتری ایجاد شود.

امنیت برنامه افزایش پیدا کند.

نگهداری و توسعه پروژه آسان‌ تر شود.

به همین دلیل، یکی از مهم‌ ترین اصول توسعه حرفه‌ ای با Nodejs این است که هیچ خطایی را نادیده نگیرید و از همان ابتدای پروژه، یک استراتژی مناسب برای مدیریت Exception ها و ثبت خطا ها در نظر بگیرید.

4- نگهداری اطلاعات حساس داخل کد:

نگهداری اطلاعات حساس داخل کد یکی از اشتباهات رایجی هست که عموما توسط توسعه دهندگان تازه کار رخ می دهد و می تواند مشکلات بسیار جدی را به همراه داشته باشد!

شاید این کار در مراحل اولیه توسعه یا پروژه های کوچک بی خطر به نظر برسد اما در عمل یکی از جدی ترین تهدید های امنیتی هم برای برنامه می باشد!

بسیاری از توسعه‌ دهندگان، به خصوص در ابتدای کار، مقادیری مانند رمز عبور پایگاه داده، کلید های API، Secret مربوط به JWT، اطلاعات سرویس‌ های ابری یا حتی Tokenهای دسترسی را مستقیما داخل فایل‌ های پروژه قرار می‌دهند. برای مثال:

const DB_URL = "mongodb://admin:password123@localhost:27017";

const JWT_SECRET = "my-secret-key";

const API_KEY = "123456789";

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

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

این نکته را هیچ وقت فراموش نکنید که یکی از اصول مهم توسعه نرم افزار این است که اطلاعات مهم و حساس باید از منطق برنامه جدا باشند! به همین دلیل نگهداری Secret ها داخل کد، یکی از رایج‌ ترین اشتباهاتی است که در توسعه پروژه های نود جی اس می توان مشاهده کرد!

راه حل چیست؟

بهترین راهکار، استفاده از متغیر های محیطی یا همان Environment Variables است. در این روش، اطلاعات حساس خارج از کد برنامه نگهداری می‌ شوند و برنامه هنگام اجرا آن‌ ها را دریافت می‌کند.

برای مثال، می‌ توان فایل .env را به شکل زیر تعریف کرد:

DB_URL=mongodb://localhost:27017/mydb

JWT_SECRET=super-secret-key

API_KEY=abcdef123456

سپس در Nodejs با استفاده از پکیج dotenv این مقادیر را بارگذاری کرد:

require("dotenv").config();

const dbUrl = process.env.DB_URL;

const secret = process.env.JWT_SECRET;

به این ترتیب، اطلاعات حساس از کدهای اصلی جدا می‌ شوند و مدیریت آن‌ ها بسیار ساده‌ تر خواهد شد.

مزایای استفاده از Environment Variables:

استفاده از فایل‌ های تنظیمات و متغیر های محیطی مزایای زیادی دارد:

افزایش امنیت برنامه

جلوگیری از افشای اطلاعات حساس

مدیریت آسان تنظیمات در محیط‌ های مختلف

کاهش احتمال خطا هنگام استقرار پروژه

سهولت در نگهداری و توسعه برنامه

امکان تغییر تنظیمات بدون تغییر کدها

یکی دیگر از اشتباهات رایج، Push کردن فایل .env به مخازن Git است. بسیاری از نشت های اطلاعاتی بزرگ، دقیقا به دلیل انتشار تصادفی این فایل اتفاق افتاده‌ اند.

به همین دلیل، بهتر است فایل .env را در .gitignore قرار دهید:

.env

همچنین در پروژه‌ های بزرگ و محیط‌ های Production، معمولا از سرویس‌ های مدیریت Secret مانند موارد زیر استفاده می‌ شود:

AWS Secrets Manager

Azure Key Vault

Google Secret Manager

HashiCorp Vault

این ابزارها امکان نگهداری و مدیریت امن اطلاعات حساس را فراهم می‌ کنند و امنیت برنامه را تا حد زیادی افزایش می‌دهند.

در نهایت این نکته را در نظر داشته باشید که امنیت یک پروژه به استفاده از فایروال یا اعتبارسنجی ورودی محدود نیست گاهی یک Secret که به اشتباه داخل کد قرار گرفته می تواند دسترسی یک هکر را به کل پروژه باز کند به همین دلیل جدا کردن اطلاعات مهم یکی از ساده ترین و مهم ترین اقداماتی هست که هر توسعه دهنده نود جی اس از همان ابتدای پروژه به آن توجه کند!

5- استفاده نکردن از Validation برای داده‌ های ورودی:

اعتماد داشتن بیش از حد به داده های ورودی و عدم اعتبار سنجی مناسب یکی دیگر از اشتباهاتی هست که در زمان توسعه پروژه های نود جی اس می توان به دفعات در پروژه های مختلف مشاهده کرد!

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

در واقعیت شما به عنوان توسعه دهنده هیچ وقت نباید به داده های ورودی اعتماد داشته باشید! چه داده ها از سمت کاربران باشد چه کلاینت و حتی API های خارجی! همه ی این ها می توانند اطلاعات ناقص یا مخرب ارسال کنند! اگر داده ها بدون اعتبار سنجی درست وارد منطق برنامه و یا پایگاه داده شوند می تواند باعث بروز مشکلات مختلفی مانند خطاهای Runtime، ثبت اطلاعات نادرست، بروز آسیب‌ پذیری‌ های امنیتی و حتی حملات مخرب ایجاد شوند.

برای مثال، فرض کنید کاربر هنگام ثبت‌ نام، اطلاعات زیر را ارسال می‌ کند:

{
  "email": "test",
  "password": "123"
}

اگر هیچ اعتبارسنجی‌ ای وجود نداشته باشد، این اطلاعات مستقیما وارد پایگاه داده می‌ شوند و کیفیت داده‌ های ذخیره شده به مرور زمان کاهش پیدا خواهد کرد.

یکی از اشتباهات رایج، ثبت مستقیم داده‌ های دریافتی از Request در پایگاه داده است:

User.create(req.body);

در این حالت، هر داده‌ ای که از سمت کاربر ارسال شود، بدون هیچ بررسی وارد سیستم خواهد شد. این مورد تنها ممکن نیست که فقط باعث خطا شود! بلکه می تواند امنیت کل ساختار پروژه را هم به خطر بیندازد!

چرا Validation اهمیت دارد؟

در بحث اعتبار سنجی تنها تصور نکنید که قرار است از خطا های ساده جلوگیری شود! اعتبار سنجی صحیح و اصولی مزایایی زیادی دارد:

جلوگیری از ذخیره اطلاعات نامعتبر

افزایش امنیت برنامه

کاهش خطاهای Runtime

جلوگیری از حملات مختلف

حفظ یکپارچگی داده‌ ها

ساده‌ تر شدن دیباگ و نگهداری پروژه

به عنوان مثال برای فیلد های ایمیل باید اعتبار سنجی اصولی گذاشته شود یعنی اینکه ایمیل باید حتما فرمت مناسب داشته باشد و از وارد کردن هر متنی به عنوان ایمیل جلوگیری شود و یا رمز عبور باید حداقل 8 کاراکتر باشد! این قوانین در سمت سرور باید بررسی می شوند و حتی اگر قبلا در سمت فرانت اند هم اعتبار سنجی شده باشند!

راه حل چیست؟

تقریبا می توان به جرات گفت که Nodejs برای همه چیز راهکاری دارد! برای این منظور هم کتابخانه های قدرتمندی برای اعتبار سنجی داده ها وجود دارد! که محبوب ترین آن Joi٬ Zod٬ Yup٬ و express-validator می باشد.

امروزه بسیاری از پروژه‌ های مدرن، به خصوص پروژه‌ های مبتنی بر TypeScript، از Zod استفاده می‌ کنند.

برای مثال:

import { z } from "zod";

const userSchema = z.object({
  email: z.email(),
  password: z.string().min(8)
});

در این حالت، اگر داده‌ های ورودی شرایط تعریف شده را نداشته باشند، قبل از رسیدن به منطق اصلی برنامه رد خواهند شد.

اعتبارسنجی فقط مخصوص فرم‌ ها نیست:

این مورد که تنها توسعه دهنده فکر کد که اعتبار سنجی تنها برای فرم های ثبت نام یا ورود می باشد هم اشتباه رایجی هست! این مورد را باید بدانید هر داده ای که وارد برنامه می شود باید اعتبار سنجی شود از جمله:

Body درخواست‌ ها

Query String ها

Route Params

Header ها

فایل‌ های آپلود شده

داده‌ های دریافتی از سرویس‌ های خارجی

به شکل ساده تر هر ورودی که کنترل آن خارج از برنامه شما باید نیاز به اعتبارسنجی دارد! و حتما باید با اعتبار سنجی به برنامه راه پیدا کند!

اعتبارسنجی در فرانت‌ اند کافی نیست و راهکار نهایی:

یکی از باورهای اشتباه این است که چون فرم‌ ها در React یا Vue اعتبارسنجی می‌ شوند، دیگر نیازی به Validation در سمت سرور وجود ندارد. در حالی که کاربر می‌ تواند به راحتی درخواست‌ ها را با ابزارهایی مانند Postman یا cURL ارسال کند و محدودیت‌ های فرانت‌ اند را دور بزند.

به همین دلیل، اعتبارسنجی سمت سرور باید به عنوان آخرین خط دفاعی برنامه در نظر گرفته شود.

در پروژه‌ های حرفه‌ای، معمولا اعتبارسنجی در لایه جداگانه‌ ای انجام می‌ شود و داده‌ های نامعتبر قبل از رسیدن به Controller ها حذف می‌ شوند. این کار باعث می‌ شود منطق اصلی برنامه تمیزتر، قابل نگهداری‌ تر و امن‌ تر باشد.

در نهایت، شاید اضافه کردن Validation در ابتدای توسعه کمی زمان‌ بر به نظر برسد، اما در بلند مدت از بروز بسیاری از باگ‌ ها، خطا ها و مشکلات امنیتی جلوگیری می‌ کند. به همین دلیل، یکی از مهم‌ ترین اصول توسعه حرفه‌ ای در Nodejs این است که به داده های ورودی هیچ وقت اعتماد نکنید!

6- استفاده نکردن از Logging مناسب:

اشتباه رایج دیگر که در این مقاله می خواهیم به آن بپردازیم عدم استفاده از لاگ گیری مناسب و نادیده گرفتن اهمیت آن توسط توسعه دهندگان در پروژه های کوچک و متوسط می باشد که عموما به چند console.log ساده اکتفا می کنند!

شاید در مراحل ابتدایی توسعه استفاده از کنسول لاگ برای بررسی مقادیر متغییر ها و دیباگ کردن پروژه کافی به نظر برسد اما زمانی که پروژه وارد محیط پروداکشن می شود شرایط کاملا متفاوت خواهد بود!

در یک برنامه واقعی این مورد را بدانید که همه چیز مطابق با انتظار شما پیش نمی رود و خطا های غیرمنتظره و درخواست های ناموفق و همچنین مشکلات مربوط به پایگاه داده رخ خواهند داد! اگر از سرویس های خارجی استفاده می کنید اختلال در آن ها هم امری رایج می باشد و طبیعتا بخشی از چرخه حیات یک نرم افزار محسوب می شود! در چنین شرایطی اگر مکانیزم مناسبی برای ثبت رویداد ها و خطا ها وجود نداشته باشد پیدا کردن علت مشکل می تواند به فرآیندی زمان بر و پییچده تبدیل شود!

بسیاری از توسعه‌ دهندگان در زمان بروز خطا تنها به این شکل عمل می‌ کنند:

console.log(error);

یا حتی:

console.error("Something went wrong");

اگرچه این روش برای دیباگ کردن‌ های ساده مفید است، اما در پروژه‌های Production مشکلات زیادی ایجاد می‌ کند. برای مثال:

اطلاعات ثبت شده ساختار مشخصی ندارند.

امکان فیلتر کردن لاگ‌ ها وجود ندارد.

سطح اهمیت خطاها مشخص نیست.

لاگ‌ها بعد از ریستارت شدن سرور از بین می‌ روند.

جستجو و بررسی خطاها دشوار می‌ شود.

امکان مانیتورینگ و تحلیل رفتار سیستم وجود ندارد.

تصور کنید برنامه شما روی چند سرور مختلف اجرا می‌ شود و یکی از کاربران گزارش می‌ دهد که هنگام ثبت سفارش با خطا مواجه شده است. اگر تنها ابزار شما چند console.log ساده باشد، پیدا کردن علت مشکل تقریبا غیرممکن خواهد بود و نیاز به بررسی و تست های فراوانی دارد که هم از نظر زمانی باعث اتلاف وقت می شود و هم ممکن است هزینه جانبی را به پروژه تحمیل کند!

چرا Logging اهمیت دارد؟

در نگاه اول خیلی از توسعه دهندگان یا افرادی که تمایل به یادگیری برنامه نویسی دارند فکر می کنند که سیستم لاگ تنها برای ثبت خطا می باشد! در صورتی که در عمل یک سیستم اصولی و حرفه ای لاگ می تواند اطلاعات ارزشمندی را در خصوص رفتار برنامه در اختیار شما قرار دهد برای مثال:

ثبت خطاها و Exception ها

بررسی درخواست‌ های کاربران

تحلیل عملکرد سیستم

شناسایی مشکلات احتمالی

مانیتورینگ سرویس‌ ها

کمک به عیب‌ یابی و دیباگ کردن

در واقع هرچقدر پروژه از نظر کاربران و وسعت رشد می کند توسعه دهنده بیشتر متوجه خواهد شد که سیستم لاگ گیری چقدر اهمیت دارد!

راه حل چیست؟

اما سوال خوب اینجاست که واقعا باید چه کاری را انجام داد که بهتر بتوان از سیستم لاگ گیری استفاده کرد؟ پاسخ به این سوال سخت نیست بهتر است توسعه دهندگان به جای استفاده صرف از console.log از کتابخانه های تخصصی که برای لاگ گیری در نود جی اس وجود دارد استفاده کنند!

محبوب ترین کتابخانه های Nodejs که در این زمینه وجود دارند:

Winston

Pino

Morgan

برای مثال، با استفاده از Winston می‌ توان لاگ‌ ها را به صورت ساختار یافته ثبت کرد:

logger.error(error);

یا:

logger.info("User logged in");

این ابزارها امکاناتی مانند موارد زیر را در اختیار شما قرار می‌ دهند:

تعیین سطح لاگ‌ ها مانند Info، Warn، Error و …

ذخیره لاگ‌ ها در فایل

ارسال لاگ‌ ها به سرویس‌ های مانیتورینگ

فرمت‌ بندی مناسب خروجی‌ ها

جستجو و تحلیل آسان‌ تر اطلاعات

به کمک این ابزارها خیلی ساده تر می توان لاگ های حرفه ای تری را در اختیار داشت و از آن ها برای بررسی و تحلیل سیستم استفاده کرد که از چرخه تولید تا اتمام کار یک پروژه می توان از آن کمک گرفت!

از ثبت اطلاعات حساس در لاگ خودداری کنید:

یکی دیگر از اشتباهات رایج، ثبت اطلاعات حساس در لاگ‌ ها است. برای مثال:

logger.info(req.body);

اگر درخواست کاربر شامل رمز عبور، توکن یا اطلاعات شخصی باشد، این داده‌ ها داخل فایل‌ های لاگ ذخیره خواهند شد و در صورت دسترسی افراد غیرمجاز، می‌ توانند به یک تهدید امنیتی جدی تبدیل شوند.

به همین دلیل، همیشه باید از ثبت اطلاعات حساس مانند رمز عبور٬ JWT Token ها٬ ٬API Key اطلاعات کارت بانکی و داده های شخصی کاربران خودداری کرد!

Logging و Monitoring در کنار یکدیگر:

این کار هم یکی از روش های اصولی و استانداردی هست که توسعه دهندگان می توانند استفاده کنند! یعنی استفاده از سیستم لاگ گیری در کنار ابزارهای مانیتورینگ!

سرویس هایی مانند ٬ELK ٬Stack ٬Grafana ٬Prometheus ٬Datadog ٬Sentry به توسعه دهنده کمک می کند وضعیت سیستم را به صورت لحظه ای مانیتور کنند و مشکلات را پیش از اینکه کاربران متوجه شوند و بخواهند اطلاع دهند حل کنید!

بهترین رویکرد:

یک سیستم لاگ استاندارد باید:

خطاها را به صورت ساختاریافته ثبت کند.

سطح اهمیت رویدادها را مشخص کند.

امکان جستجو و تحلیل اطلاعات را فراهم کند.

اطلاعات حساس را ذخیره نکند.

در محیط Production قابل استفاده باشد.

با ابزارهای مانیتورینگ یکپارچه شود.

در نهایت باید این نکته را هم در نظر داشت که خطا ها اجتناب ناپذیر هست و در هر سیستم بزرگ و کوچکی هم رخ خواهند داد! در واقع چیزی که یک پروژه را حرفه ای می کند این نیست که نباید خطا داشته باشد بلکه قدرت شناسایی خطا و بررسی و رفع آن می باشد!

به همین دلیل است که داشتن یک سیستم لاگ گیری حرفه ای از مهم ترین اصول توسعه و نگهداری پروژه های نود جی اس می باشد و نداشتن آن یکی از اشتباهات رایج توسعه دهندگان Nodejs!

7- ساختار نامناسب پروژه و سازماندهی نادرست کدها:

این این اشتباه یکی از اشتباهاتی هست که هر توسعه دهنده ای حداقل یکبار در مسیر کاری خود مرتکب می شود! و آن هم بی توجهی به ساختار پروژه و نحوه سازماندهی کدها می باشد!

این مشکل معمولا در ابتدای توسعه چندان جدی به نظر نمی رسد زیرا پروژه کوچک است و همه چیز قابل مدیریت است! اما وقتی بخش های جدید و قابلیت های متنوع به پروژه اضافه می شود و پروژه با افزایش تعداد فایل و بزرگ تر شدن رو به رو می شود همین مورد تبدیل به یک بی نظمی می شود و این هرج و مرج به یکی از بزرگترین مشکلات پروژه تبدیل خواهد شد!

بسیاری از پروژه‌ها با یک فایل app.js یا server.js شروع می‌ شوند و در ابتدا همه چیز طبیعی به نظر می‌ رسد. اما به مرور زمان، Route ها، منطق تجاری، Query های پایگاه داده، Middleware ها و تنظیمات مختلف همگی داخل چند فایل محدود قرار می‌ گیرند و پروژه به تدریج به مجموعه‌ ای از کدهای به هم ریخته تبدیل می‌ شود.

برای مثال، در بسیاری از پروژه‌ها می‌توان چنین ساختاری را مشاهده کرد:

project/

├── app.js
├── user.js
├── product.js
├── database.js

یا حتی بدتر، هزاران خط کد داخل یک فایل:

app.js

در چنین شرایطی، پیدا کردن یک باگ ساده یا اضافه کردن یک قابلیت جدید می‌ تواند به فرآیندی زمان‌ بر و خسته‌ کننده تبدیل شود.

چرا ساختار پروژه اهمیت دارد؟

همانطور که گفته شد در پروژه های کوچک شاید ساختار مناسب مشکلی ایجاد نکند اما زمانی که پروژه رشد می کند این مورد تاثیر مستقیم بر موارد زیر خواهد داشت:

خوانایی کدها

سرعت توسعه قابلیت‌ های جدید

تست‌ پذیری پروژه

همکاری اعضای تیم

نگهداری و رفع باگ‌ ها

مقیاس‌ پذیری سیستم

بنابراین در بسیاری از مشکلاتی که در پروژه های بزرگ نود جی اس دیده می شود علت آن این نیست که خود نود جی اس ضعف دارد بلکه به دلیل ساختار و معماری نامناسبی هست که در کدها وجود دارد و توسعه دهنده به آن توجه نکرده است!

یکی از اشتباهات رایج این است که تمام مسئولیت‌ ها در Controller ها قرار می‌ گیرند:

دریافت درخواست

اعتبارسنجی

منطق تجاری

Query های پایگاه داده

ساخت پاسخ نهایی

این موضوع باعث می‌ شود Controller ها به مرور زمان بسیار بزرگ و پیچیده شوند و تغییر یک بخش از سیستم روی بخش‌ های دیگر نیز تاثیر بگذارد.

اما راه حل چیست؟

بهتر است پروژه از همان ابتدا به صورت لایه‌ای طراحی شود و هر بخش مسئولیت مشخصی داشته باشد.

برای مثال، ساختار زیر یکی از الگوهای رایج در پروژه‌ های Nodejs است:

src/

├── controllers/
├── routes/
├── services/
├── repositories/
├── models/
├── middlewares/
├── validations/
├── utils/
├── config/
└── app.js

در این ساختار که مشاهده می کنید هر بخش وظیفه مختص به خودش را دارد که به صورت خلاصه می توان گفت:

Controller:

مسئول دریافت درخواست و ارسال پاسخ هستند.

Service:

منطق اصلی کسب‌ و کار را مدیریت می‌کنند.

Repository:

وظیفه ارتباط با پایگاه داده را بر عهده دارند.

Middleware:

عملیات مشترک مانند احراز هویت یا مدیریت خطا را انجام می‌دهند.

Validation:

مسئول بررسی داده‌های ورودی هستند.

Config:

تنظیمات برنامه را مدیریت می‌کنند.

وقتی این مسئولیت‌ ها تفکیک می شود هر بخش به صورت مشخص قابل بررسی هست و کمک می کند پروژه بسیار خواناتر و قابل نگهداری تر باشد!

اگر در شروع کار فکر کنید که پروژه کوچک هست و نیاز به ساختار بندی مشخص و مناسب ندارد شاید درست باشد اما تجربه ثابت کرده است که پروژه ها به مرور زمان رشد می کنند و بزرگتر می شوند و تغییر ساختار در مراحل پایانی توسعه یا حتی بعد از عملیاتی شدن پروژه بسیار دشوارتر و پر هزینه تر می شود!

البته این موضوع به معنی پیچیده کردن بیش از حد پروژه نیست! هدف٬ ایجاد تعادل بین سادگی و سازماندهی مناسب است! لازم نیست از همان روز اول معماری پیچیده پیاده سازی کنید اما بهتر است کد ها به گونه ای باشد که در آینده مشکلی برای توسعه و نگهداری وجود نداشته باشد!

در پروژه‌ های بزرگ‌ تر معمولا از الگو هایی مانند موارد زیر استفاده می‌ شود:

Layered Architecture

Repository Pattern

MVC

Clean Architecture

Domain Driven Design (DDD)

انتخاب هر کدام از این معماری‌ ها به اندازه پروژه و نیازهای آن بستگی دارد، اما نکته مهم این است که از ایجاد وابستگی‌ های پیچیده و فایل‌ های چند هزار خطی جلوگیری شود.

یک پروژه Nodejs با ساختار مناسب باید ویژگی‌ های زیر را داشته باشد:

مسئولیت‌ ها به خوبی تفکیک شده باشند.

فایل‌ ها و پوشه‌ ها سازماندهی مشخصی داشته باشند.

توسعه قابلیت‌ های جدید ساده باشد.

تست‌ نویسی آسان‌ تر انجام شود.

اعضای جدید تیم بتوانند سریع‌ تر با پروژه آشنا شوند.

نگهداری و رفع باگ‌ ها زمان کمتری نیاز داشته باشد.

در نهایت باید این نکته را بدانید که کیفیت یک پروژه به تعداد قابلیت ها یا سرعت توسعه وابسته نیست بلکه ساختار و معماری اصولی هست که پروژه دارد و یکی از مهم‌ ترین عواملی که باعث می‌ شود یک پروژه در بلند مدت پایدار، قابل توسعه و قابل نگهداری باقی بماند.

سرمایه‌ گذاری روی ساختار پروژه از همان ابتدای توسعه، تصمیمی است که در آینده بار ها ارزش خود را نشان خواهد داد و شما را از دردسرهای بزرگی که در ابتدا حتی نمی توانید تصور کنید نجات می دهد!

8- استفاده نکردن از TypeScript:

درست هست که نود جی اس و جاوا اسکریپت ترکیب بسیار قدرتمندی را تشکیل می دهند و خیلی از پروژه های موفق نیز با همین ترکیب توسعه پیدا کردند اما با بزرگ تر شدن پروژه ها و افزایش تعداد فایل ها در کنار اضافه شدن اعضای جدید به تیم توسعه٬ یکی از مشکلاتی که کم کم خودش را نشان خواهد داد نبود Type Safety و افزایش خطا های Runtime است.

به همین دلیل است که بسیاری از توسعه‌ دهندگان و تیم‌ های حرفه‌ ای امروزه TypeScript را به عنوان انتخاب اول خود برای توسعه پروژه‌های Nodejs در نظر می‌ گیرند.

جاوا اسکریپت یک زبان پویا محسوب می شود و همین موضوع هم یکی از دلایل محبوبیت آن است اما این انعطاف پذیری بالا٬ در پروژه های بزرگ می تواند به یک نقطه ضعف تبدیل شود! بسیاری از خطا ها تنها در زمان اجرای برنامه مشخص می شود! یعنی زمانی که برنامه در حال سرویس دهی به کاربران هست و این خطا ها می تواند تجربه کاربری ناموفق و داون تایم های بی موقع را تحمیل کند!

برای مثال، فرض کنید تابعی برای دریافت اطلاعات کاربر نوشته‌ اید:

function getUser(user) {
  return user.name.toUpperCase();
}

اگر مقدار user یا فیلد name وجود نداشته باشد، برنامه در زمان اجرا با خطا مواجه خواهد شد. چنین خطا هایی در پروژه‌ های بزرگ و تیمی بسیار رایج هستند و پیدا کردن آن‌ ها همیشه آسان نیست.

TypeScript چه مشکلی را حل می‌ کند؟

TypeScript یک Superset از JavaScript است که قابلیت Type Safety را به پروژه اضافه می‌ کند. به عبارت دیگر، بسیاری از خطا ها قبل از انتشار نهایی در زمان توسعه پیدا می شود و توسعه دهنده می تواند آن را حل کند تا در مراحل پایانی و بعد از استفاده کاربران دچار مشکل نشود!

برای مثال:

interface User {
  name: string;
}

function getUser(user: User) {
  return user.name.toUpperCase();
}

در این حالت، اگر داده‌ ای با ساختار اشتباه به تابع ارسال شود، TypeScript قبل از اجرای برنامه خطا را نمایش می‌ دهد و در همین مرحله مشکل حل می شود!

چرا TypeScript در پروژه‌ های Nodejs محبوب شده است؟

در چند سال اخیر، TypeScript به استانداردی غیررسمی برای توسعه پروژه‌ های متوسط و بزرگ تبدیل شده است. بسیاری از فریم‌ ورک‌ ها و ابزار های مدرن مانند:

NestJS

Prisma

TypeORM

Next.js

به طور کامل از TypeScript پشتیبانی می‌ کنند و حتی برخی از آن‌ ها بر پایه TypeScript طراحی شده‌ اند.

استفاده از TypeScript مزایای متعددی دارد:

کاهش خطا های Runtime

خوانایی بهتر کدها

Autocomplete و IntelliSense قدرتمندتر

Refactor آسان‌ تر

نگهداری ساده‌ تر پروژه

همکاری بهتر بین اعضای تیم

افزایش کیفیت کد ها

مستند سازی بهتر ساختار داده‌ ها

این موارد تنها بخش هایی از مزیت هایی هست که استفاده از TypeScript در پروژه ها به همراه دارد!

آیا همیشه باید از TypeScript استفاده کرد؟

لزوما خیر نیاز نیست همیشه از TypeScript استفاده شود برای مثالا وقتی پروژه شما کوچک هست یا می خواهید یک Prototype ساده بسازید و یا به تنهایی روی پروژه کار می کنید همچنان جاوا اسکریپت گزینه مناسب تری محسوب می شود!

اما وقتی پروژه قرار است رشد کند و تعداد فایل ها و وابستگی ها افزایش پیدا کند TypeScript هست که بیشتر خودنمایی می کند و مزیت های خوبی را به پروژه اضافه می کند.

البته مهاجرت به TypeScript الزام نیست، اما می‌ توان آن را نوعی سرمایه‌ گذاری بلند مدت روی کیفیت و نگهداری پروژه دانست.

اگرچه استفاده نکردن از TypeScript یک اشتباه به معنای واقعی نیست، اما در پروژه‌ های بزرگ و تیمی، می‌ تواند باعث افزایش پیچیدگی، بیشتر شدن خطا ها و دشوارتر شدن نگهداری کد ها در آینده شود.

به همین دلیل، بسیاری از توسعه‌ دهندگان باتجربه معتقدند که اگر امروز قرار باشد یک پروژه جدید Nodejs را از ابتدا شروع کنند، احتمالا TypeScript یکی از اولین انتخاب‌ های آن‌ ها خواهد بود.

9- استفاده بیش از حد از پکیج‌ های NPM و وابستگی‌ های غیرضروری:

همانطور که قبلا هم اشاره کردیم وجود اکوسیستم بزرگ و قدرتمند NPM که دارای میلیون ها کتابخانه و پکیج های آماده می باشد یکی از علت های محبوبیت بالای نود جی ای می باشد!

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

خیلی از توسعه دهندگانی که در شروع توسعه پروژه های نود جی اس هستند و شاید تجربه چند پروژه را نداشته باشند برای کوچک ترین نیاز های خود سراغ نصب کتابخانه می روند و یک پکیج جدید را نصب می کنند حتی برای کارهای خیلی ساده ای مانند فرمت کردن تاریخ٬ تولید شناسه تصادفی یا تبدیل رشته ها! این در حالی است که بسیار ها از این قابلیت ها با API های داخلی جاوا اسکریپت یا Nodejs قابل پیاده سازی هست!

برای مثال، نصب یک پکیج برای انجام چنین کاری چندان منطقی به نظر نمی‌ رسد:

capitalize("hello");

در حالی که می‌ توان آن را با چند خط کد ساده پیاده‌ سازی کرد و نیاز به نصب وابستگی جدید در پورژه نباشد!

const capitalize = str =>
  str.charAt(0).toUpperCase() + str.slice(1);

ممکن است اضافه کردن یک پکیج به تنهایی مشکلی ایجاد نکند، اما زمانی که پروژه شامل ده‌ ها یا حتی صد ها وابستگی مختلف شود، مشکلات متعددی به وجود می‌ آید.

چرا استفاده بیش از حد از پکیج‌ ها مشکل‌ ساز است؟

هر پکیجی که نصب می کنید بخشی از پروژه شما خواهد بود و طبیعی هست مسئولیت نگهداری و استفاده از آن کاملا برعهده شما می باشد! علاوه بر این موضوع مورد مهم دیگر اینجاست که بسیاری از این کتابخانه خود دارای وابستگی های دیگری هستند و همین موضوع زنجیره ای از وابستگی های پیچیده را ایجاد می کند!

استفاده بیش از حد از پکیج های NPM به مرور مشکلات زیادی را به خصوص با اضافه شدن بیش از اندازه کتابخانه ها ایجاد می کند که به صورت مختصر می توان گفت:

افزایش حجم پروژه

پیچیده‌ تر شدن فرایند بروزرسانی

افزایش احتمال بروز آسیب‌ پذیری‌ های امنیتی

وابستگی بیش از حد به کتابخانه‌ های شخص ثالث

دشوار شدن نگهداری پروژه

افزایش زمان Build و Deployment

احتمال متوقف شدن توسعه یا حذف شدن پکیج توسط توسعه‌ دهنده اصلی

یکی از مشکلات معروفی که در این زمینه رخ داد مربوط به پکیج Left-pad بود که حذف شدن این پکیج کوچک از اکوسیستم NPM باعث شد هزاران پروژه و ابزار در سراسر دنیا دچار مشکل شوند!

این مورد به ما نشان می دهد که حتی کوچک ترین وابستگی ها می تواند تاثیر بسیار زیادی روی کل پروژه داشته باشد.

یکی از اشتباهاتی که خیلی در پروژه ها دیده می شود این است که توسعه دهنده شروع به نصب کتابخانه ها و وابستگی ها می کند بدون اینکه مواردی نظیر:

تعداد دانلودهای ماهانه

آخرین زمان بروزرسانی

تعداد مشارکت‌ کنندگان پروژه

تعداد Issue های باز

وجود آسیب‌ پذیری‌ های امنیتی

کیفیت مستندات

را مورد بررسی قرار دهد! گاهی یک پکیج سال ها هست که بروزرسانی نشده و استفاده از آن در آینده مشکلات زیادی ایجاد خواهد کرد! این را در نظر داشته باشید اگر یک پکیج دچار مشکل امنیتی شود امنیت کل پروژه شما به مخاطره خواهد افتاد!

آیا همیشه باید از پکیج‌ های آماده استفاده کنیم؟

یک سوال رایجی که تقریبا برای تمام توسعه دهندگانی که ابتدای راه هستند وجود دارد و زیاد پرسیده می شود همین سوال می باشد که همیشه باید از پکیج های آماده استفاده کنیم؟

پاسخ به این سوال واضح است: خیر! البته منظور این نیست که همه چیز از صفر نوشته شود! استفاده از کتابخانه های معتبر و شناخته شده یکی از دلایل اصلی سرعت بالای نود جی اس می باشد اما بین استفاده هوشمندانه از پکیج ها و وابستگی بیش از حد باید تعادل برقرار کرد

استفاده از کتابخانه هایی نظیر Express و Prisma کاملا منطقی هست چون این ابزارها سال های زیادی هست که توسعه پیدا کرده اند و جامعه کاربری بزرگی هم دارند و بروزرسانی های مداومی برای آن ها داده می شود اما نصب یک پکیج برای حل یک مشکل بسیار ساده همیشه بهترین انتخاب نیست.

از ابزارهای بررسی آسیب‌ پذیری استفاده کنید:

قبلا در مقاله امنیت نود جی اس از صفر تا صد که در ابتدای همین مقاله هم به آن اشاره کردیم این موضوع را مورد بررسی قرار دادیم ولی برای اهمیت بالایی که دارد در این مقاله هم به آن اشاره می کنیم!

نود جی اس ابزارهای زیادی را در اختیار توسعه دهندگان قرار می دهد تا وضعیت وابستگی را مورد چک کنند.

برای مثال:

npm audit

این دستور آسیب‌ پذیری‌ های امنیتی موجود در پکیج‌ های نصب شده را نمایش می‌ دهد.

همچنین با دستور زیر می‌ توان بسیاری از مشکلات را برطرف کرد:

npm audit fix

علاوه بر این، ابزار هایی مانند Dependabot و Snyk نیز می‌ توانند در شناسایی آسیب‌ پذیری‌ ها و بروزرسانی وابستگی‌ ها کمک کنند.

چه کاری انجام دهیم بهتر است؟

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

آیا واقعا به این پکیج نیاز دارم؟

آیا این قابلیت با امکانات داخلی Nodejs یا JavaScript قابل پیاده‌ سازی است؟

آیا این کتابخانه فعال و بروز است؟

آیا جامعه کاربری مناسبی دارد؟

آیا ریسک امنیتی خاصی ایجاد نمی‌ کند؟

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

فراموش نکنید که استفاده نادرست از کتابخانه ها می تواند به یک نقطه ضعف جدی در پروژه تبدیل شود و یک توسعه دهنده حرفه ای صرفا تعداد زیادی کتابخانه نصب نمی کند بلکه تلاش می کند با کمترین وابستگی ممکن٬ پروژه ای کاملا پایدار و امن ایجاد کند!

10- عدم استفاده از Cache و بهینه‌ سازی درخواست‌ های تکراری:

استفاده از کش امروزه در تمام پروژه هایی که چه با نود جی اس توسعه یافته باشند یا زبان های برنامه نویسی دیگر به امری بدیهی تبدیل شده است! حتی یک پروژه وردپرس ساده هم برای بهترین عملکرد خود نیاز به کش دارد!

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

بسیاری از توسعه‌ دهندگان برای هر درخواست، بدون توجه به اینکه داده مورد نظر قبلا دریافت شده یا خیر، مستقیما به سراغ پایگاه داده می‌ روند:

const user = await User.findById(id);

خوب این مورد را در نظر داشته باشید اگر هزاران کاربر در طول روز بخواهند همین اطلاعات مشابه را درخواست کنند این Query باید بارها و بارها اجرا شود و نتیجه چنین رویکردی این است که فشار روی پایگاه داده بالا می رود و منابع سخت افزاری مانند Ram و Cpu بیش از حد مصرف می شود و سرعت پاسخگویی کاهش پیدا خواهد کرد!

گاها پروژه هایی را می بینیم که اطلاعات سرویس ها و داده های آن ها به ندرت تغییر می کند در این پروژه ها استفاده از کش حتی اهمیت بیشتری دارد چون داده ها تقریبا ثابت هست و نیاز نیست با هر بار درخواست Query زده شود!

برای مثال:

اطلاعات محصولات فروشگاه

لیست دسته‌ بندی‌ ها

اطلاعات کاربران

نتایج جستجو

تنظیمات سایت

گزارش‌ ها و آمار ها

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

Cache چیست و چرا اهمیت دارد؟

کش به معنای ذخیره موقت داده هایی هست که احتمال استفاده مجدد از آن ها وجود دارد! این یکی از ساده ترین تعریف هایی هست که برای کش وجود دارد!

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

استفاده از Cache مزایای متعددی دارد:

افزایش سرعت پاسخ دهی

کاهش فشار روی پایگاه داده

مصرف کمتر منابع سرور

افزایش مقیاس‌ پذیری برنامه

بهبود تجربه کاربری

کاهش هزینه‌ های زیرساخت

این ها بخشی از دلایلی هست که باعث شده استفاده از کش را به یکی از مهم ترین تکنیک های بهینه سازی پروژه های نود جی اس تبدیل کند! و عدم استفاده از آن را به یک اشتباه مهلک برای هر توسعه دهنده ای بدانیم!

راه حل چیست؟

یکی از محبوب ترین ابزار ها برای پیاده سازی کش در نود جی اس استفاده از Redis می باشد! ردیس یک پایگاه داده مبتی بر RAM می باشد و همین مورد باعث می شود سرعت بسیار بالایی داشته باشد و یک گزینه بسیار خوب برای ذخیره داده های موقت باشد!

برای مثال، قبل از اجرای Query می‌ توان ابتدا Cache را بررسی کرد:

const cachedUser = await redis.get(id);

if (cachedUser) {
  return JSON.parse(cachedUser);
}

و در صورتی که داده در Cache وجود نداشته باشد:

const user = await User.findById(id);

await redis.set(id, JSON.stringify(user));

به این ترتیب، درخواست‌ های بعدی مستقیما از Redis پاسخ داده می‌ شوند و نیازی به مراجعه مجدد به پایگاه داده نخواهد بود.

بسته به نوع پروژه، می‌توان از روش‌های مختلفی برای Cache استفاده کرد:

Redis

Node-cache

Memory Cache

Query Cache

CDN

Reverse Proxy Cache

Browser Cache

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

یک اشتباه در مبحث کش:

همانطور که گفته شد کش می تواند برای سیستم مفید واقع شود و سرعت را افزایش دهد اما اگر بیش از حد داده ها کش شود هم یک اشتباه دیگر هست!

تمام اطلاعات برای ذخیره در کش مناسب نیستند و داده هایی که در طی روز چندین مرتبه تغییر می کنند باعث می شود که اطلاعات قدیمی به کاربر نمایش داده شود و نباید برای این داده ها از کش استفاده کرد!

به همین دلیل، هنگام استفاده از Cache باید به موارد زیر توجه کرد:

مدت زمان اعتبار داده‌ ها

نحوه بروزرسانی Cache

حذف داده‌ های قدیمی

همگام‌ سازی اطلاعات با پایگاه داده

در غیر این صورت، Cache می‌ تواند به جای افزایش عملکرد، مشکلات جدیدی ایجاد کند.

چه زمانی وقت استفاده از کش هست؟

اگر در پروژه خود با موارد زیر رو به‌ رو هستید، احتمالا زمان استفاده از Cache فرا رسیده است:

تعداد زیادی درخواست تکراری دارید.

Query های پایگاه داده سنگین هستند.

زمان پاسخ‌ دهی برنامه افزایش یافته است.

مصرف CPU و RAM بالا رفته است.

کاربران زیادی به صورت همزمان از سرویس استفاده می‌ کنند.

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

اشتباهات رایجی که پروژه های نود جی اس رخ می دهد لزوما به این دلیل نیست که کدها بد نوشته شده اند! گاهی بزرگترین بهبود های عملکردی را زمانی شاهد هستیم که نه تغییری در الگوریتم ها داده شده و نه منطق برنامه تغییر کرده است! صرفا از اقدامات غیر ضروری جلوگیری شده است کش دقیقا همین کار را انجام می دهد یعنی از تکرار بیهوده پردازش ها و Query ها جلوگیری می کند!

به همین دلیل، بسیاری از برنامه‌ های مقیاس‌ پذیر و پرترافیک، بخش مهمی از عملکرد خود را مدیون استفاده صحیح از مکانیزم‌ های Cache هستند. اگرچه ممکن است در پروژه‌ های کوچک نیازی به آن احساس نشود، اما با رشد تعداد کاربران و افزایش حجم داده‌ها، نبود یک استراتژی مناسب برای Cache می‌ تواند به یکی از مهم‌ ترین عوامل افت عملکرد و افزایش هزینه‌ های زیرساخت تبدیل شود.

چکیده:

در جدول زیر می توانید موارد گفته شده را به شکل خلاصه مشاهده بفرمایید:

چک لیست نهایی:

Event Loop را Block نکنید.

از Error Handling مناسب استفاده کنید.

به ورودی‌ ها اعتماد نکنید.

اطلاعات حساس را داخل کد قرار ندهید.

Logging حرفه‌ ای داشته باشید.

از وابستگی‌ های غیرضروری دوری کنید.

برای داده‌ های پرتکرار Cache در نظر بگیرید.

ساختار پروژه را از ابتدا مشخص کنید.

در پروژه‌ های بزرگ TypeScript را فراموش نکنید.

به Performance و امنیت از ابتدای توسعه توجه کنید.

نتیجه گیری:

نود جی اس به خودی خود نه سریع ترین راه حل برای همه مسائل هست و نه یک پلتفرم جادویی که بدون رعایت اصول حرفه ای توسعه بتوانید یک پروژه پایدار و سریع بسازید!

واقعیت این است که موفقیت یا شکست یک پروژه بیش از آنکه به فناوری وابسته باشد به تصمیم هایی وابسته هست که در طول توسعه گرفته می شود!

این نکته که خیلی از مشکلاتی که توسعه دهندگان در مراحل بعد با آن رو به رو می شوند در واقع از اشتباهاتی ناشی می شود که در مراحل ابتدایی توسعه انجام شده هست و اکثر این اشتباهات هم خیلی پیچیده یا عجیب نیستند!  اغلب این مشکلات از بی‌ توجهی به اصول ساده‌ ای مانند مدیریت صحیح خطا ها، اعتبارسنجی داده‌ ها، ساختار مناسب پروژه یا بهینه‌ سازی عملکرد به وجود می‌ آیند! مسائلی که شاید در ابتدای توسعه چندان مهم به نظر نرسند، اما با رشد پروژه و افزایش تعداد کاربران، تأثیر واقعی خود را نشان می‌ دهند.

این نکته را در نظر داشته باشید که هدف از مطرح شدن این موارد پیچیده تر شدن بی دلیل پروژه ها نیست! و نیاز نیست معماری های سنگین را از همون مراحل ابتدایی ایجاد کنید در واقع این موارد به این خاطر است که از شیوه های درست و متناسب با نیاز پروژه های خود بهره مند شوید! مهم این است که از همان ابتدا دید درستی نسبت به مسیر رشد پروژه داشته باشید و بدانید که کدام تصمیم در آینده می تواند به نقطه ضعف یا قوت پروژه تبدیل شود!

در نهایت، یک توسعه‌ دهنده حرفه‌ ای کسی نیست که صرفا کدهای بیشتری بنویسد یا از ابزارهای بیشتری استفاده کند! بلکه کسی است که بتواند با انتخاب‌ های درست، پروژه‌ ای بسازد که علاوه بر عملکرد مناسب، در بلند مدت نیز قابل نگهداری، قابل توسعه و قابل اعتماد باقی بماند.

شاید جلوگیری از این اشتباهات در نگاه اول تغییر بزرگی ایجاد نکند، اما مجموع همین تصمیم‌ های کوچک است که تفاوت بین یک پروژه معمولی و یک پروژه پایدار و حرفه‌ای را رقم می‌ زند.