چگونه Technology Stack پروژه را انتخاب کنیم؟

Technology Stack (پشتهٔ فناوری) مجموعه‌ای از زبان، فریم‌ورک، پایگاه‌داده، کش، سرور و الگوی معماری است که محصول روی آن ساخته و اجرا می‌شود. انتخابش فقط سلیقهٔ توسعه‌دهنده نیست؛ روی سرعت تحویل، هزینهٔ عملیات، استخدام، امنیت و امکان تغییر مسیر اثر می‌گذارد.

اشتباه رایج این است که از «چه چیزی الان ترند است؟» شروع کنید. نقطهٔ درست شروع، Use Case (مورد استفاده)، قیود تیم، و ریسک‌های قابل‌تحمل است. این مقاله شش لایه را جدا می‌کند: Framework، Language، Database، Cache، Server، Architecture — و برای هر لایه سؤال تصمیم می‌دهد.

مقاله‌های بعدی همین بلوک (۱۱۶ تا ۱۲۱) جزئیات زبان، دیتابیس، سایز سرور، مونولیت در برابر میکروسرویس، و چارچوب ارزیابی کل پروژه را باز می‌کنند. اینجا نقشهٔ کلی تصمیم است تا قبل از خرید ابزار، مرز مسئله روشن شود.

پاسخ کوتاه

Stack را لایه به لایه و از محدودیت‌های واقعی انتخاب کنید: چه کاری باید درست انجام شود، تیم چه مهارتی دارد، داده چه شکلی دارد، ترافیک چه الگویی دارد، و عملیات را چه کسی نگه می‌دارد. زبان و فریم‌ورک را با Use Case بسنجید نه با جدول محبوبیت؛ دیتابیس را با مدل داده و نیاز تراکنش؛ کش را فقط وقتی هزینهٔ خواندن تکرارشونده مشخص شد؛ سرور را با Workload؛ معماری را با پیچیدگی سازمانی نه با مد.

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

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

شش لایهٔ تصمیم

Language: از کار شروع کنید نه از برند

طبق معرفی رسمی Node.js، این زمان‌اجرا برای کار I/O ناهمگام و اتصال همزمان زیاد مناسب طراحی شده و به توسعه‌دهندگان فرانت امکان اشتراک زبان با بک‌اند می‌دهد. طبق صفحهٔ Applications در Python.org، پایتون در وب، علم داده، اتوماسیون و آموزش کاربرد گسترده دارد. این‌ها تعریف «بهترین زبان» نیستند؛ تعریف تناسب کارند.

قبل از انتخاب، سه جمله بنویسید: غالب بار CPU است یا I/O؟ آیا همان تیم فرانت باید بک‌اند را هم بسازد؟ آیا کتابخانهٔ دامنه (پرداخت، GIS، ML) در اکوسیستم موجود است؟ پاسخ این سه سؤال، نصف بحث‌های بی‌پایان را قطع می‌کند.

Framework: قرارداد در برابر آزادی

فریم‌ورک سرعت شروع و یکنواختی تیم را می‌خرد و در عوض مسیر و وابستگی می‌آورد. برای API ساده گاهی کتابخانهٔ سبک کافی است؛ برای پنل ادمین، احراز هویت، فرم و گزارش، فریم‌ورک کامل‌تر هزینهٔ چرخ‌اختراع را کم می‌کند.

• اندازهٔ تیم و نرخ جابه‌جایی نیرو: قرارداد مشترک onboarding را کوتاه می‌کند.
• افق عمر محصول: وابستگی بلندمدت را با پشتیبانی LTS و جامعه بسنجید.
• نیاز امنیتی: احراز هویت، CSRF، و اعتبارسنجی ورودی را از نو ننویسید مگر دلیل قوی دارید.

قانون عملی: اگر تیم زیر پنج نفر است و محصول MVP است، فریم‌ورکی را بگیرید که مسیر Happy Path را کوتاه کند و مستند رسمی خوانا داشته باشد. تعویض فریم‌ورک بعداً گران است؛ تعویض زودهنگام به‌خاطر «خسته‌شدن از ترند» معمولاً گران‌تر است.

Database: مدل داده را قبل از موتور بکشید

PostgreSQL در مستندات رسمی خود را ORDBMS با پرس‌وجوی پیچیده، کلید خارجی، تریگر، یکپارچگی تراکنشی و MVCC معرفی می‌کند. این ویژگی‌ها برای دادهٔ رابطه‌ای با قیود کسب‌وکار نقطهٔ شروع قوی است — نه چون «همه Postgres می‌کنند»، بلکه چون مدل دادهٔ اکثر کسب‌وکارها رابطه‌ای است.

اول موجودیت‌ها، روابط، و نیاز تراکنش را روی کاغذ بکشید؛ بعد موتور را انتخاب کنید. اگر داده سندوار و شِماپَرْان است، مسیر سندمحور معنا دارد. اگر فقط کش و شمارنده و نشست می‌خواهید، Redis به‌عنوان لایهٔ حافظه‌ای کنار منبع حقیقت می‌نشیند نه به‌جای آن.

Cache: وقتی درد خواندن را اندازه گرفتید

طبق مستندات Redis، این سامانه یک data store حافظه‌ای است که به‌عنوان کش، ساختار داده، و واسط پیام به کار می‌رود. کش را وقتی اضافه کنید که: خواندن تکراری از دیتابیس یا سرویس بیرونی گران شده، تأخیر قابل‌اندازه‌گیری است، و سیاست انقضا/باطل‌سازی را می‌توانید بنویسید.

کش بدون استراتژی invalidation باگ منطقی می‌سازد: کاربر قیمت کهنه می‌بیند و اعتماد از دست می‌رود. اول ایندکس و پرس‌وجو را درست کنید؛ بعد کش. مقالهٔ ۰۳۹ مفهوم کش را جدا توضیح می‌دهد.

Server: Workload نه حدس

سایز سرور را از الگوی کار بسازید: آیا پردازنده را محاسبات سنگین مشغول می‌کند یا حافظه را مجموعهٔ دادهٔ فعال؟ آیا دیسک IOPS می‌خواهد یا فقط فضای فایل؟ ترافیک ثابت است یا فصلی؟ پاسخ این‌ها به RAM، CPU و Storage جهت می‌دهد — بدون نیاز به بنچمارک‌های فروشگاهی جعلی.

برای شروع، یک محیط Staging شبیه Production با مانیتورینگ ساده بسازید و با بار واقعی یا شبیه‌سازی معقول رشد دهید. مقالهٔ ۱۱۹ همین منطق را باز می‌کند.

Architecture: پیچیدگی را بخرید وقتی لازم است

Martin Fowler در Monolith First استدلال می‌کند میکروسرویس‌ها Premium پیچیدگی دارند و برای سیستم‌های ساده‌تر مونولیت مناسب‌تر است؛ بسیاری از داستان‌های موفق میکروسرویس از شکستن یک مونولیت بالغ آمده‌اند. معماری را با تعداد تیم‌های مستقل، نیاز استقرار جدا، و مرز دامنهٔ پایدار بسنجید — نه با اسلاید کنفرانس.

چک‌لیست عملی قبل از قفل کردن Stack

1. یک صفحهٔ یک‌پاراگرافی از محصول و سه Use Case حیاتی بنویسید.
2. مهارت فعلی تیم و امکان استخدام محلی را صادقانه امتیاز دهید.
3. مدل داده و نیاز تراکنش را بدون نام برند بکشید.
4. الگوی ترافیک و حساسیت تأخیر را حدس مستند کنید (فرض را بنویسید).
5. حداقل عملیات: backup، لاگ، مانیتورینگ، و مسیر حادثه را مشخص کنید.
6. یک Spike یک‌هفته‌ای روی مسیر بحرانی بسازید و ریسک را با کد بسنجید نه با نظر.
7. تصمیم را در ADR کوتاه ثبت کنید تا شش ماه بعد بحث از صفر شروع نشود.

چه چیزهایی را عمداً عقب بیندازید؟

• چندزبانه کردن بک‌اند قبل از اثبات نیاز مرزی.
• چند پایگاه ناهمگون قبل از اینکه یک منبع حقیقت پایدار شود.
• Orchestration سنگین وقتی یک یا دو سرویس دارید.
• ابزار مشاهده‌پذیری سازمانی وقتی هنوز لاگ ساخت‌یافته ندارید.

عقب انداختن به‌معنی انکار نیست؛ به‌معنی خریدن اطلاعات قبل از خریدن پیچیدگی است. مقالهٔ ۱۱۶ همین منطق را برای «تازه‌ترین فناوری» باز می‌کند.

نقش صاحب محصول در انتخاب Stack

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

در جلسهٔ تصمیم، هر گزینه را با سه ستون مقایسه کنید: زمان تحویل سه ماه اول، هزینهٔ نگهداشت سال اول، و ریسک استخدام. عددی که نمی‌دانید را با بازه و فرض بنویسید؛ خالی نگذارید تا بعداً معلوم شود حدس بوده.

جمع‌بندی

انتخاب Technology Stack یک مسابقهٔ محبوبیت نیست؛ یک طراحی محدودیت است. زبان و فریم‌ورک را با کار و تیم، دیتابیس را با مدل داده، کش را با درد اندازه‌گیری‌شده، سرور را با Workload، و معماری را با پیچیدگی واقعی سازمان هماهنگ کنید. از سادهٔ قابل‌نگهداری شروع کنید و پیچیدگی را وقتی شواهد آمد اضافه کنید.

اگر می‌خواهید همین منطق را تا ارزیابی کل پروژه جلو ببرید، مقالهٔ ۱۲۱ چارچوب بسته‌کنندهٔ این سری را می‌دهد.

منابع و مراجع

• Node.js Learn — Introduction to Node.js: https://nodejs.org/en/learn/getting-started/introduction-to-nodejs
• Python.org — Applications for Python: https://www.python.org/about/apps/
• PostgreSQL Documentation — What Is PostgreSQL?: https://www.postgresql.org/docs/current/intro-whatis.html
• Redis Docs — Get started: https://redis.io/docs/latest/get-started/
• Martin Fowler — Monolith First: https://martinfowler.com/bliki/MonolithFirst.html

قبل از قفل کردن ابزار، یک Spike کوتاه روی مسیر حیاتی محصول اجرا کنید و نتیجه را با تیم محصول در میان بگذارید.