یک زمانی و شاید همچنان جملاتی مثل این جملات را زیاد شنیدم یا می شنوم :
این جملات مخصوص ایران نیستند شاید اینجا بیشتر بشنویم اما به نظر من جهان شمول هستند. بار ها و بار ها مقایسه های آماری که از فریم ورک ها یا کتابخانه های مختلف در اینترنت پیدا می کنیم , اما در نهایت به نظر من این موارد نمی توانند کمک شایانی به ما در توسعه نرم افزار کنند. حال چرا عنوان مقاله را فلسفه , حلقه مفقوده دنیای توسعه نرم افزار گذاشتم؟
به دلیل اینکه در دنیای بسیار گونه گونه نرم افزار دیدگاه کلی گرایانه جواب نمی دهد , بلکه دقیقا شما باید قبل از انتخاب , فلسفه کار یا کارهایی که آن سرویس قرار است انجام بدهد رو درک کرده باشید و به صورت کامل ماهیت سرویس رو فهمیده باشید .
منطقی نگاه کنیم مهمترین موردی که برای ماژول لاگ وجود داره این هست که بتونیم تحت هر شرایطی دیتای لاگ رو ثبت کنیم , اینکه بعدا از این دیتا به چه صورت و در چه قالبی استفاده کنیم بحث دیگریست که راجب آن هم می شود صحبت کرد.پس مهمترین کار ما در ماژول لاگ ثبت دیتای لاگ است , ماهیت دیتای لاگ به دلیل رابطه ای نبودن ( یعنی نیازی نیست ماهیت رابطه ای داشته باشه ) بهتره در دیتابیس های No-Sql ثبت بشه , یک دلیل دیگر هم این هست که ماهیت کاری که در لاگ انجام میشه Transactional نیست.حال سوال مهمی پیش میاد اینکه از کدام دیتابیس No-Sql برای لاگ استفاده کنیم ؟ خب شاید اولین گزینه به ذهن خیلی ها دیتابیس های معروف و پرکاربرد باشه , اما چرا باید انتخاب بشه ؟ دلایل و پارامتر های ما برای انتخاب چیه ؟ اصلا چه پارامتر هایی برای انتخاب وجود داره ؟
اگر دقت کنید پارامتر Popularity رو تقریبا در آخر لیست قرار دادم , این یعنی اینکه اگر نت فلیکس با مثلا 1000 Micro Service برای ماژول لاگ از دیتابیس معروفی استفاده میکنه دلیلی نداره که این دیتابیس برای سرویس شما جوابگو باشه , شما اول باید به سوال هایی که در مورد سرویس خودتون وجود داره جواب بدین و ببینید اگر دیتابیس مورد نظر میتونه پاسخگوی تمام سوالات شما باشه پس می تواند انتخاب مناسبی باشد ( البته یک مرحله Sandbox هم است که انتخاب شما رو منطقی تر می کنه) . من در اینجا می تونم برای مثال به یک دیتابیس اشاره کنم , Apache Cassandra به چند دلیل :
جمع بندی در مورد سوال :
بنابراین اگر فقط هدف ثبت لاگ باشه شما از هر دیتابیسی می تونین استفاده کنید اما باید فلسفه کاری ماژول لاگ رو کاملا درک کرده باشید تا بتونین انتخاب بهتری داشته باشین. اگر به ما بگن چرا از Cassandra استفاده میکنیم ؟ وقتی نتفلیکس داره استفاده میکنه به نظر من جواب حرفه ای نیست , اینکه مطلع باشیم کدام کمپانی ها برای چه کاری و کجا دارن استفاده میکنن عالیه و خیلی کمک کننده هست و اصطلاحا دیتای بنچمارک به درد میخوره ولی برای انتخاب نهایی کافی نیست.این مثال کوچک فقط در مورد ماژول لاگ بود و مطمئنا از مقیاس کوچکتری نسبت به انتخاب دیتابیس برای تایپ های دیگر پروژه برخوردار است .بنابراین این فقط یک مثال کوچک در مورد انتخاب دیتابیس برای پروژه ای کوچک بود.
یکی از گزینه هایی که معمولا در این قسمت مطرح میشه به دلیل سرعت بالای اون Nodejs هست.من بار ها و بار ها به این نکته اشاره کردم ولی نیاز هست اینجا کامل تر بگم.
فرض کنید شما سرویسی دارید که در قسمت Back-end اون یک درخواست ارسال میشه , درخواست به سمت دیتابیس ارسال میشه , خروجی گرفته میشه. اینجا ممکنه 2 تا اتفاق بیفته ( محدود به 2 تا نیست بیشتر یک مثاله ) :
در مورد اول نظر شخصی من این هست که به هیچ عنوان از نود جی اس استفاده نکنم . اما چرا ؟ به دلیل اینکه ماهیت نود جی اس Single Thread که این به خاطر جاوا اسکریپته.ممکنه شما بگید خب کلاستر میکنیم و از چندین نود استفاده میکنیم , اما این تغییری در ماهیت Nodejs ایجاد نمیکنه, بنابراین انتخاب من در اینجا :
خواهد بود. جاوااسکریپت برای کارهایی که قرار هست با پردازنده کار داشته باشه ساخته نشده و این رو در تحلیل ها در نظر بگیرید که اگر قراره عملیات شما از قدرت پردازنده استفاده کنه عملا نود جی اس به کار شما نمیاد .بنابراین سریع بودن معیار مهمی هست اما کافی نیست و نمیتونیم فقط بر اساس همین 1 معیار انتخاب ما Nodejs باشه.
در مورد دوم هم باید بگوییم که می توانیم از Nodejs استفاده کنیم اما باز هم باید ببنیم میزان Concurrent کاربران استفاده کننده از سرویس در کدام قسمت است. یکی از بیشترین کاربرد هایی که من شخصا برای نود قائل هستم , سرویس هایی از این نوع :
بنابراین شاید بهتر بگم برای Application Server باید خیلی حواسمون باشه که بتونه مقیاس پذیر باشه.
یا مثلا می شنونم که حتما در سرویس از Graphql استفاده کنید , خب چرا ؟ چرا باید استفاده کنم ؟ اصلا ذات به وجود آمدن Graphql چی بوده ؟ وقتی از این مورد در سرویس هایمان استفاده می کنیم عملا داریم به End-Point های سرویسمون شکل اریفیس متر رو تزریق می کنیم و آیا واقعا سرویس ما به این شکل احتیاج داره ؟
در مورد قسمت فرانت هم به نظرم بیشتر دعوا بر سر این هست که تیم توسعه چگونه با اون کار کنه و فکر میکنم قسمت کاربر در این زمینه داره هر روز کمرنگ تر میشه. دلیل این حرف هم این است که چرا باید فریم ورکی مثل انگولار جی اس حذف بشه و فریم ورک هایی پدیدار بشه که خیلی عمیق نگاه کنیم خیلی کار عجیب و غریب تری نسبت به انگولار جی اس انجام نمی دهند. یکی از ایراد هایی که به انگولار جی اس گرفته میشه امکان اینکه از این فریم ورک در معماری Micro Service استفاده کنیم وجود ندارد. خب این حرف عملا اشتباهه و چرا نمیشه استفاده کرد ؟ این رو هم جدیدا شنیدم که به نظرم درست نیست.
اینقدر تکنولوژی ها زیاده شده و در آن غرق شده ایم که اصلا فراموش کرده ایم قرار است وب 3 در همین سال های پیش رو از راه برسد. وب 3 که بیاید خیلی از تکنولوژی هایی که داریم استفاده می کنیم مطمئنا از کاربرد کمتری برخوردار خواهد بود. در دنیای وب 3 تمرکز دیتا در یک نقطه خاص دیگر عملا معنی ندارد , سرویس های ارائه دهنده کلود , هاستینگ و یا سرویس هایی مثل AWS , Azure , Google Cloud و خیلی های دیگه با چالش جدی دنیای وب 3 مواجه خواهند شد . وقتی کاربران در دنیای وب 3 بیشتر به نگهداشت دیتا پیش خودشان تشویق می شوند , سرویس های شما هم باید این قضیه را پیش بینی کند. پیشنهاد میکنم کتاب شاهکار "دنیای پس از گوگل " نوشته نویسنده محترم دنیای سیلیکون ولی یعنی جرج گیلدر را مطالعه کنید. در این کتاب توضیح می دهد که چرا گوگل اگر قدم های درستی بر ندارد حتی در دنیای وب 3 گوگلی هم وجود نخواهد داشت.
لینک های کتاب :
در نهایت این مقاله قرار نیست چیزی رو توصیه کنه , این مقاله نظرات شخصی بر اساس سال ها تجربه در دنیای نرم افزار است و تنها هدف این است که در دنیای امروز تکنولوژی ها که کمپانی ها حال می خواهند Open Source باشند یا Commercial یا هر نوع دیگری , درگیر استفاده مدام و به روز نباشیم و برای سرویس هایمان تحلیل درستی از دلیل استفاده آنها داشته باشیم. این همان فلسفه است , این همان چرایی است که باید در مورد قسمت های سرویس هایمان سوال کنیم و دنبال جواب های درستی برایش باشیم.در واقع نگاهمان باید بیشتر به سمت Solution Architecture باشد زیرا در این قسمت است که بیشتر نگاه فلسفی غالب می شود و چرا هایی ایجاد می کند که پاسخ به آنها کمک به ایجاد مسیری بهتر برای رشد سرویس شما خواهد بود.
