فلسفه , حلقه مفقوده دنیای توسعه نرم افزار

فلسفه , حلقه مفقوده دنیای توسعه نرم افزارچرا فلسفه حلقه مفقوده است ؟یک زمانی و شاید همچنان جملاتی مثل این جملات را زیاد شنیدم یا می شنوم :برای Back-end فقط Node.js اگر میخوای برای Back-end مهاجرت کنی بهتر هست از Node.js استفاده کنی اگر میخواهی برای قسمت API مهاجرت کنی از Flusk استفاده کنی بهتره برای فرانت فقط React یا Angular یا Vueبرای دیتابیس اگر تصمیم داری از No-Sql استفاده کنی فقط MongoDBو خیلی جملات دیگر از این دست این جملات مخصوص ایران نیستند شاید اینجا بیشتر بشنویم اما به نظر من جهان شمول هستند. بار ها و بار ها مقایسه های آماری که از فریم ورک ها یا کتابخانه های مختلف در اینترنت پیدا می کنیم , اما در نهایت به نظر من این موارد نمی توانند کمک شایانی به ما در توسعه نرم افزار کنند. حال چرا عنوان مقاله را فلسفه , حلقه مفقوده دنیای توسعه نرم افزار گذاشتم؟به دلیل اینکه در دنیای بسیار گونه گونه نرم افزار دیدگاه کلی گرایانه جواب نمی دهد , بلکه دقیقا شما باید قبل از انتخاب , فلسفه کار یا کارهایی که آن سرویس قرار است انجام بدهد رو درک کرده باشید و به صورت کامل ماهیت سرویس رو فهمیده باشید .بهتره من منظورم رو با یک مثال بهتر برسونم , برای ماژول لاگ از چه دیتابیسی استفاده می کنید ؟منطقی نگاه کنیم مهمترین موردی که برای ماژول لاگ وجود داره این هست که بتونیم تحت هر شرایطی دیتای لاگ رو ثبت کنیم , اینکه بعدا از این دیتا به چه صورت و در چه قالبی استفاده کنیم بحث دیگریست که راجب آن هم می شود صحبت کرد.پس مهمترین کار ما در ماژول لاگ ثبت دیتای لاگ است , ماهیت دیتای لاگ به دلیل رابطه ای نبودن ( یعنی نیازی نیست ماهیت رابطه ای داشته باشه ) بهتره در دیتابیس های No-Sql ثبت بشه , یک دلیل دیگر هم این هست که ماهیت کاری که در لاگ انجام میشه Transactional نیست.حال سوال مهمی پیش میاد اینکه از کدام دیتابیس No-Sql برای لاگ استفاده کنیم ؟ خب شاید اولین گزینه به ذهن خیلی ها دیتابیس های معروف و پرکاربرد باشه , اما چرا باید انتخاب بشه ؟ دلایل و پارامتر های ما برای انتخاب چیه ؟ اصلا چه پارامتر هایی برای انتخاب وجود داره ؟قدرت دیتابیس در قسمت Insert به خصوص در زمانی که سرویس ها اصطلاحا Concurrent Transaction دارند . نحوه کلاسترینگ دیتابیس از چه نوعی هست ؟ آیا از نوع Master - Slave هست یا Shared یا هر نوع دیگر. برخورد نود ها در کلاستر به چه صورت هست ؟ آیا هر نود مستقل عمل میکنه یا اینکه هر نود میتونه Read/Write داشته باشه یا هر نود وظایف محدودی دارهدیتابیس برای لحظاتی که در دسترس نیست چه تمهیدی داره و آیا از بین رفتن دیتا می تونه جلوگیری کنه؟چه نوع ساختار دیتایی پشتیبانی میکنه ؟این دیتابیس در چه کمپانی هایی در چه سرویس هایی استفاده می شود؟و کلی پارامتر دیگهاگر دقت کنید پارامتر Popularity رو تقریبا در آخر لیست قرار دادم , این یعنی اینکه اگر نت فلیکس با مثلا 1000 Micro Service برای ماژول لاگ از دیتابیس معروفی استفاده میکنه دلیلی نداره که این دیتابیس برای سرویس شما جوابگو باشه , شما اول باید به سوال هایی که در مورد سرویس خودتون وجود داره جواب بدین و ببینید اگر دیتابیس مورد نظر میتونه پاسخگوی تمام سوالات شما باشه پس می تواند انتخاب مناسبی باشد ( البته یک مرحله Sandbox هم است که انتخاب شما رو منطقی تر می کنه) . من در اینجا می تونم برای مثال به یک دیتابیس اشاره کنم , Apache Cassandra به چند دلیل :مطابق با بنچمارک هایی که وجود داره تونستند با یک کانفیگ سرور نسبتا متوسط 15 میلیون رکورد رو در 1 دقیقه ثبت کنند. این پارامتر به من میگه که قدرت این دیتابیس در قسمت Insert فوق العاده است.کلاستر این دیتابیس از نوعی هست که اگر یک یا تعدادی از نود های شما Down بشن لود بالانسر به صورت اتوماتیک Optimize میشه و بقیه نود ها وظیفه دیتابیس رو انجام میدن ( می توانید نود های مستقلی داشته باشید )شما در این دیتابیس می تونین کار های متفاوتی با نود ها انجام بدین , هر نود میتونه مستقل عمل کنه و عملیات Read / Write رو انجام بده.شما در Apache Cassandra میتونین تنظیم کنید که دیتای ارسالی به نود ها به چه صورت باهاشون برخورد بشه , آیا میخواین در صورتی که نود Down شده دیتای ارسالی از دست نره , میتونین تنظیم کنید که هر وقت اون نود مورد نظر Up شد دیتا رو ثبت کنه یا دیتا بره سمت نود های فعال دیگه.پس این تا حد زیادی خیال من رو بابت از دست ندادن دیتا راحت می کنه. یکی از ماموریت های مهم این دیتابیس این هست که تا جای ممکن Single Point Of Failure نداشته باشه و این یعنی پارامتر مهم برای لاگساختار دیتایی که پشتیبانی میکنه : structured, semi-structured, and unstructuredعملیات Replication به چه صورت است ؟در چه کمپانی هایی استفاده میشه ؟ فیس بوک (اینستاگرام ) - اوبر - نتفلیکس - اسپاتیفای - ردیت - ایبیجمع بندی در مورد سوال :بنابراین اگر فقط هدف ثبت لاگ باشه شما از هر دیتابیسی می تونین استفاده کنید اما باید فلسفه کاری ماژول لاگ رو کاملا درک کرده باشید تا بتونین انتخاب بهتری داشته باشین. اگر به ما بگن چرا از Cassandra استفاده میکنیم ؟ وقتی نتفلیکس داره استفاده میکنه به نظر من جواب حرفه ای نیست , اینکه مطلع باشیم کدام کمپانی ها برای چه کاری و کجا دارن استفاده میکنن عالیه و خیلی کمک کننده هست و اصطلاحا دیتای بنچمارک به درد میخوره ولی برای انتخاب نهایی کافی نیست.این مثال کوچک فقط در مورد ماژول لاگ بود و مطمئنا از مقیاس کوچکتری نسبت به انتخاب دیتابیس برای تایپ های دیگر پروژه برخوردار است .بنابراین این فقط یک مثال کوچک در مورد انتخاب دیتابیس برای پروژه ای کوچک بود.مثال دیگری که خیلی میتونه کمک کننده باشه, برای قسمت Back-end سرویس ها از چه چیزی استفاده می کنید ؟یکی از گزینه هایی که معمولا در این قسمت مطرح میشه به دلیل سرعت بالای اون Nodejs هست.من بار ها و بار ها به این نکته اشاره کردم ولی نیاز هست اینجا کامل تر بگم.فرض کنید شما سرویسی دارید که در قسمت Back-end اون یک درخواست ارسال میشه , درخواست به سمت دیتابیس ارسال میشه , خروجی گرفته میشه. اینجا ممکنه 2 تا اتفاق بیفته ( محدود به 2 تا نیست بیشتر یک مثاله ) :قبل از ارسال به سمت کلاینت پردازش روی دیتا (درگیر شدن پردازنده سرور ) انجام و بعد ارسال میشهدیتای گرفته شده با عملیات مپ یا بدون مپ برای کلاینت ارسال میشهدر مورد اول نظر شخصی من این هست که به هیچ عنوان از نود جی اس استفاده نکنم . اما چرا ؟ به دلیل اینکه ماهیت نود جی اس Single Thread که این به خاطر جاوا اسکریپته.ممکنه شما بگید خب کلاستر میکنیم و از چندین نود استفاده میکنیم , اما این تغییری در ماهیت Nodejs ایجاد نمیکنه, بنابراین انتخاب من در اینجا :جاواگوروبیدات نت کورپایتونو ...خواهد بود. جاوااسکریپت برای کارهایی که قرار هست با پردازنده کار داشته باشه ساخته نشده و این رو در تحلیل ها در نظر بگیرید که اگر قراره عملیات شما از قدرت پردازنده استفاده کنه عملا نود جی اس به کار شما نمیاد .بنابراین سریع بودن معیار مهمی هست اما کافی نیست و نمیتونیم فقط بر اساس همین 1 معیار انتخاب ما Nodejs باشه. در مورد دوم هم باید بگوییم که می توانیم از Nodejs استفاده کنیم اما باز هم باید ببنیم میزان Concurrent کاربران استفاده کننده از سرویس در کدام قسمت است. یکی از بیشترین کاربرد هایی که من شخصا برای نود قائل هستم , سرویس هایی از این نوع :سرویس های Real Time مثل پیام رسان هاسرویس های Reserve مثل سرویس های ارائه دهنده تیکتسرویس های استریم ( ویدیو - موسیقی )بنابراین شاید بهتر بگم برای Application Server باید خیلی حواسمون باشه که بتونه مقیاس پذیر باشه.یا مثلا می شنونم که حتما در سرویس از Graphql استفاده کنید , خب چرا ؟ چرا باید استفاده کنم ؟ اصلا ذات به وجود آمدن Graphql چی بوده ؟ وقتی از این مورد در سرویس هایمان استفاده می کنیم عملا داریم به End-Point های سرویسمون شکل اریفیس متر رو تزریق می کنیم و آیا واقعا سرویس ما به این شکل احتیاج داره ؟در مورد قسمت فرانت هم به نظرم بیشتر دعوا بر سر این هست که تیم توسعه چگونه با اون کار کنه و فکر میکنم قسمت کاربر در این زمینه داره هر روز کمرنگ تر میشه. دلیل این حرف هم این است که چرا باید فریم ورکی مثل انگولار جی اس حذف بشه و فریم ورک هایی پدیدار بشه که خیلی عمیق نگاه کنیم خیلی کار عجیب و غریب تری نسبت به انگولار جی اس انجام نمی دهند. یکی از ایراد هایی که به انگولار جی اس گرفته میشه امکان اینکه از این فریم ورک در معماری Micro Service استفاده کنیم وجود ندارد. خب این حرف عملا اشتباهه و چرا نمیشه استفاده کرد ؟ این رو هم جدیدا شنیدم که به نظرم درست نیست.فلسفه آینده نگرانه , وب 3.0اینقدر تکنولوژی ها زیاده شده و در آن غرق شده ایم که اصلا فراموش کرده ایم قرار است وب 3 در همین سال های پیش رو از راه برسد. وب 3 که بیاید خیلی از تکنولوژی هایی که داریم استفاده می کنیم مطمئنا از کاربرد کمتری برخوردار خواهد بود. در دنیای وب 3 تمرکز دیتا در یک نقطه خاص دیگر عملا معنی ندارد , سرویس های ارائه دهنده کلود , هاستینگ و یا سرویس هایی مثل AWS , Azure , Google Cloud و خیلی های دیگه با چالش جدی دنیای وب 3 مواجه خواهند شد . وقتی کاربران در دنیای وب 3 بیشتر به نگهداشت دیتا پیش خودشان تشویق می شوند , سرویس های شما هم باید این قضیه را پیش بینی کند. پیشنهاد میکنم کتاب شاهکار "دنیای پس از گوگل " نوشته نویسنده محترم دنیای سیلیکون ولی یعنی جرج گیلدر را مطالعه کنید. در این کتاب توضیح می دهد که چرا گوگل اگر قدم های درستی بر ندارد حتی در دنیای وب 3 گوگلی هم وجود نخواهد داشت.لینک های کتاب :Goodreads LinkTaaghche Linkجمع بندیدر نهایت این مقاله قرار نیست چیزی رو توصیه کنه , این مقاله نظرات شخصی بر اساس سال ها تجربه در دنیای نرم افزار است و تنها هدف این است که در دنیای امروز تکنولوژی ها که کمپانی ها حال می خواهند Open Source باشند یا Commercial یا هر نوع دیگری , درگیر استفاده مدام و به روز نباشیم و برای سرویس هایمان تحلیل درستی از دلیل استفاده آنها داشته باشیم. این همان فلسفه است , این همان چرایی است که باید در مورد قسمت های سرویس هایمان سوال کنیم و دنبال جواب های درستی برایش باشیم.در واقع نگاهمان باید بیشتر به سمت Solution Architecture باشد زیرا در این قسمت است که بیشتر نگاه فلسفی غالب می شود و چرا هایی ایجاد می کند که پاسخ به آنها کمک به ایجاد مسیری بهتر برای رشد سرویس شما خواهد بود.