19 راه ساده برای Node.js کار بهتر شدن - بخش اول

همه جا با Node!این روزها افق نور خورشید جاوااسکریپت بی پایانه! برای رسیدن به سرمرزهای این افق هر برنامه‌نویسی علاوه بر دانش عمومی در حوزه‌ی Node.js باید در مورد ترندها، شیوه‌ها و تکنولوژی‌های بروز در این حوزه آگاه باشه و بدونه در کدوم پروژه از چه متدهایی برای بهبود کل فرآیند استفاده کنه. با هم در دو قسمت در مورد 19 روش و مهارتی که میتونه برای ما به عنوان یک Developer حوزه Node.js ارزش‌آفرینی کنه صحبت میکنیم. با خوندن این مطلب اصلا دچار ترس و اضطراب نشید، کمتر برنامه‌نویسی وجود داره که توی همه‌ی این موارد حرفه‌ای باشه و حرف زیادی برای گفتن داشته باشه. این مباحث بیشتر یک نقشه‌ی راه و یک طرح کلی برای کشیدن نقشه‌ی یادگیری و ارتقا شخصی برنامه‌نویس‌های Node.js است. 1- افزودن نوع و اسکیما: با کاندیداتوری Typescriptنیم نگاهی به Type Scriptاز لذت‌های اصلی جاوااسکرپیت Type Less و یا بدون نوع بودن اونه. اما تحقیقات نشون میده که کدنویسی بدون مشخص کردن نوع متغیرها میتونه که تعداد خطاها رو افزایش بده (منبع). مخصوصا با افزایش اندازه‌ی پروژه و پیچیدگی نرم‌افزار بدون نوع بودن همه چیز میتونه پیچیدگی‌های بیشتر برای بررسی خطاها به وجود بیاره. این موضوع به این معنی نیست که از فردا راه بیافتیم و تمام نوع‌های پروژه‌مون رو مشخص کنیم، بلکه میتونیم با استفاده از ارزیابی‌کردن (validate) مدل‌ها و ورودی‌هامون از کلی حجم خطایی که ممکنه رخ بده، کم کنیم. یک راه ساده بر این کار هم استفاده از typechecker ای که فیسبوکه (گیتهاب پروژه). در نهایت یکی از بهترین راه‌ها استفاده از syntax همراه با نوع Typescript استفاده کنیم. استفاده از Typescript یکی از ترندهای حوزه Node.js و جاوااسکریپت در سالهای اخیر بوده. حتی میتونید فریمورک‌های سمت Front رو هم مثل Vue با Typescript امتحان کنید. حتی شاید وسوسه شدید که از امکاناتی شبیه Interface و abstract کلاسها هم استفاده کنید. مثال‌ها:Explicit models schemas with JSON SchemaStatic typing over vanilla JS using Facebook flowTyped syntax with Typescript2-استفاده از Linterها یا ارزیاب‌های کدهر چقدر هم که برنامه‌نویس خبره‌ای باشیم باز هم ممکن موقع برنامه‌نویس چیزی رو فراموش کنیم و یک باگ برای آینده پروژه‌مون کنار بزاریم. Linterها مثل ناهار مجانی می‌مونند، چند دقیقه صرف نصب‌شون می کنیم و می‌تونند ما رو از یک عالمه خطا در طول عمر برنامه نجات بدن. از فراموش کردن یک semi colon ساده تا مشخص کردن promiseهای resolve نشده از جمله کارهایی هست که خطایاب‌ها برامون انجام میدن. اگر اهل برنامه‌نویسی سی شارپ با Visual Studio باشید حتما با Resharper آشنا هستید. یک مقدار CPU و RAM میدید ولی عوضش سرعت برنامه‌نویسی و خطایابی خیلی بهتری دارید. چند مثال از کارهایی که Linter انجام میدن:eslint-plugin-chai-expect can discover tests without assertionseslint-plugin-promise can discover promises with no resolve (your code will never continue)eslint-plugin-security can discover eager regex expressions (that might get used for DOS attacks)3- عمیق‌تر کردن دانش معماری و طراحی نرم‌افزارDesign patternاین روزها توی اکوسیستم نرم‌افزاری همه از مایکروسرویس‌ها حرف میزنند و MVC هم مهمترین الگوی طراحی این روزها نرم‌افزار شده. مشکل کار کجاست؟ خیلی بعیده که بتونیم تمام نیازهایی شبیه منطق پروژه، نقش‌ها، لایه مدیریت دیتا و مابقی نیازهای نرم‌افزارهامون رو توی قالب دو تا کلاس Controller و Model ذخیره کنیم. تازه کسی صحبت از این نمیکنه هر کدوم از مایکروسرویس‌ها رو به صورت مستقل چه جوری مدیریت و طراحی کنیم. این نقل قول از عمو باب رو هم اضافه کنم که:MVC is a delivery mechanism, not an application architectureبه نظر میاد که نباید ترسی از استفاده از Patternهای پیچیده‌تر و معماری‌های مقیاس‌پذیرتر داشته باشیم. مخصوصا با افزایش اندازه‌ی پروژه انتخاب یک معماری صحیح‌تر خودش رو بیشتر نشون میده. میتونید برای ادامه‌ی این مبحث مثال‌های زیر رو دنبال کنید:Did you read my Node.js best practices section 1 — architecture?code of this nice Node.js boilerplatedata mapper pattern see a shortened version of this Novel book here4-استفاده از Async-Hooks برای Trace بهتر contextوقتی که از معماری غیرهمزمان استفاده میکنیم مهمترین اتفاق اینه که درخواستها context خودشون رو از دست میدن و در طول چرخه درخواست-پاسخ همه‌ی متغیرهای درخواست حفظ نمیشن. مشکل اینجاست که برنامه‌نویس‌های دوست دارن که تمام اطلاعات طول یک درخواست رو به صورت پیوسته log کنند که بعدا بتونند اشکالات و گلوگاه‌های سیستم رو به راحتی شناسایی کنند. مکانیسم‌هایی برای تزریق کدها به این فرآیند وجود داره که تمام نیازهای ما رو از دنبال کردن متغیرهای یک Context در طول چرخه‌ی عمرش پوشش بده. در ادامه چند مثال برای ارتقای Tracing توی Node.js لیست شده:cls-hooked allows sharing variables and context through the entire request life-cycleJaeger client will visualize the entire request flowLearn about async-hooks opportunities and how to code against it5-مطالعه‌ی بیشتر در مورد معماری ServerLess فراتر از سرورهای محلیخیلی از شرکت‌ها توی گذشته یک یا چندین سرور فیزیکی در محل شرکت یا دیتاسنتر داشتند و تمام عملیات مرتبط با سرور رو خودشون انجام میدادن. این روزها معماری FasS یا Function as a service یکی از ترندهای اصلی دنیا نرم‌افزار هست. شما با استفاده از این معماری قرار نیست که دوباره همه چیز رو خودتون پیاده‌سازی کنید یا تمام چیزهایی رو که لازم دارید نصب، config و نگهداری کنید. تنها بر اساس سرویس‌هایی که احتیاج دارید و مقدار مصرفتون، هزینه میکنید و به راحتی هر موقع که خواستید تقاضای امکانات سخت‌افزاری بیشتری از ارائه‌دهنده‌ی خدمات FasS می‌کنید. آشنایی با معماری Server less و استفاده از صحیح از اون شما رو میتونه یک مرحله بالاتر از برنامه‌نویس‌های دیگه قرار بده.اگر خارج از ایران زندگی میکنید، حتما سر به خدمات شرکت‌هایی مثل آمازون، گوگل و مایکروسافت توی این زمینه بزنید. اگر ایران زندگی میکنید برای شروع میتونید به ابر فندق یا سرویس‌های شرکت آرمان مراجعه کنید.برای مطالعه بیشتر:AWS Lambda SAM tool allows defining and running FaaS locallyAWS Lambda now supports canary deployments!AWS Lambda layers6- یادگیری ویژگی‌ها و امکانات جدید جاوا اسکریپتهمیشه برنامه‌نویس‌هایی وجود دارند که شبیه گذشته کد می‌زنند. علاوه بر واجب بودن یادگیری JS 6 باید یک نگاه‌هایی هم به نسل‌های دیگه جاوااسکریپت مثل JS 7 و JS 8 و .. بندازید و ویژگی‌ها و امکاناتشون رو یاد بگیرید. همچنین سایت https://node.green مرجع خوبی برای این هست که بدونید از چه امکانی میتونید توی کدوم نسخه از node استفاده کنید و چه ویژگی‌ها رو هنوز بلد نیستید که میتونه کدهاتون رو ساده‌تر و تمیزتر کنه.Async iteratorspromise-finally7-جدی‌تر گرفتن grpc و استفاده‌ی عملی از GraphQLانتخاب‌های متفاوت برای یک مسئله‌ی همیشگیسال‌های زیادیه که rest api سلطان بلامنازع الگوی نوشتن سرویس‌ها توی حوزه‌ی وب هست. اینکه هر موجودیتی endpoint خاص خودش رو داشته باشه و بتونیم از قیدهای http برای مدیریت درخواست‌ها استفاده کنیم از مهمترین مزایا الگوی rest api هست. اما همه چیز rest نیست و rest هم نمیتونه همه چیز رو پشتیبانی کنه. به دلیل ماهیت و معماری rest api و Stateless بودن اون امکان پیاده‌سازی سرویس‌هایی مثل چت‌های آنلاین با rest api امکان پذیر نیست. همچنین مشکل n + 1 دررخواست از دیگر مشکل‌های اصلی سرویس‌های مبتنی بر rest api هست. توی این سال‌های گذشته دو الگوی GraphQL و grpc به شدت محبوب و پر کاربرد شدن. حتی اگر آگهی‌های استخدامی این روزهای ایران رو هم نگاه کنید، شرکت‌هایی زیادی وجود دارند که برای استخدام node.js کار مورد علاقه‌شون شرط آشنایی با GraphQL رو هم مطرح کردند. بهتر هست به این دو تکنولوژی نگاه دقیق‌تری بندازید و حداقل یک پروژه با GraphQL انجام بدید. مطالعه بیشتر:Learning by contrasting is great — REST vs Graph vs grpcSkim through a GraphQL, Node &amp;amp; Express tutorialWatch a short YouTube (11 min) — what is GraphQL?8- فراتر رفتن از unit و integration تست‌هاتوی سال‌های گذشته برنامه‌نویسی با وجود مایکروسرویس‌ها، معماری server less و فرانت‌های تغییرهای اساسی به خودش دیده اما توی حوزه‌ی تست نویسی ما هنوز و اغلب تنها از unit تست‌ها، integration تست‌ها و end-to-end تست‌ها استفاده میکنیم (واقعا استفاده میکنیم؟ :) ). میشه گفت این روزها تنها این تست‌ها کافی نیست، باید روش‌ها و متدهای جدیدتری هم توی این زمینه یاد بگیریم. برای شروع میتونید لینک‌های زیر رو بررسی کنید:Consumer-driven contractsSnapshot testsComponent testsSee my YouTube video on “Beyond Unit Tests: 5 Shiny Node.JS Test Types (2018)9-یادگیری ابزارهای مانیتورینگ کد بر روی سروراین روزها این قدر مشغول یادگرفتن کتابخونه‌های جدید و ترندهای برنامه‌نویسی در هنگام Develop کردن هستیم که فراموش میکنیم بخش اصلی کار وقتی هست که کدهای ما توی محیط Production قرار میگیره. میدونم که مانیتورینگ سرور رو میتونند دوستان شبکه کار به عهده بگیرند اما به عنوان برنامه‌نویس هم باید کمی با این موضوعات آشنا باشیم. مثلا بدونیم که زمان پاسخدهی هر کدوم از سرویس‌هامون به طور متوسط چند میلی ثانیه است یا اینکه برای هر رکوئست چقدر CPU و RAM استفاده میکنیم. تازه علاوه بر این‌ها باید به درستی بتونیم خطاها رو ردیابی کنیم و یا زودتر از هر کسی دیگه‌ای از اشکالات سرورمون خبردار بشیم. برای شروع میشه این مطالب رو بررسی کرد:Read about the 4 monitoring ‘Golden signals’Read Google Site Reliability Engineering book, or at least the chapter on monitoringrequest-stats10- فکر کردن مثل هکرها: یادگیری ابزارهای هک برای تمرین دفاع مناسباگر نتونید مثل یک هکر فکر کنید و ابزارهای حمله‌ی اون‌ها رو بلد باشید، هیچ وقت نمی‌تونید یک استراتژی مناسب برای دفاع در نظر بگیرید. توی سال 2019 انجام یک کار کافی نیست، باید بلد بشید چه طوری از نرم‌افزارتون و داده‌های مشتری‌هاتون محافظت کنید و در صورت مورد حمله واقع شدن خسارت رو به حداقل برسونید. به هشدارهای امنیتی هم توجه کنید و همیشه حواستون به Patchهای امنیتی ابزارهاتون باشه. همچنین فراموش نکنید امنیت چیزی نیست که در انتهای پروژه به کدهاتون اضافه کنید، بلکه چیزیه که از همون روز اول باید یک نقشه‌ی مناسب براش داشته باشید. برای مرور بیشتر:OWASP ZAP — a rich assessment &amp; penetrationRead my list of Node.js Security best practicesاین نوشته ترجمه‌ی آزادی از این مطلب در مدیومه. سعی میکنم خیلی زود قسمت دومش رو مثل همین ترجمه‌ی آزاد منتشر کنم.