https://virgool.ir/feed/@support769fa2026-11-11 12:51:20https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@support769https://virgool.ir/@support769/بک-اند-آماده-کِی-جواب-می-دهد-و-کِی-نه-dzyrqdvieut9هر بار که بحث «بک‌اند آماده» یا Backend as a Service بالا می‌گیرد، جواب‌ها دو دسته‌اند: یا «عالیه، دیگه بک‌اند نمی‌نویسی»، یا «اسباب‌بازیه، برای پروژه‌ی جدی به درد نمی‌خوره». هر دو غلط‌اند، چون هیچ‌کدام نمی‌گویند این ابزار دقیقاً چه چیزی را جایگزین می‌کند.بگذارید از همان شروع کنیم، چون بقیه‌ی تصمیم از آن بیرون می‌آید.یک BaaS دقیقاً جای چه چیزی را می‌گیرد«بک‌اند» یک چیز نیست. اگر بک‌اند یک اپلیکیشن معمولی را باز کنید، معمولاً این‌ها را می‌بینید:۱. یک دیتابیس و مدل داده۲. یک لایه‌ی CRUD روی آن — بخوان، بساز، ویرایش کن، حذف کن۳. احراز هویت و مدیریت کاربر۴. کنترل دسترسی: چه کسی چه سطری را می‌بیند۵. آپلود و سرو فایل۶. منطق کسب‌وکار مخصوص همین محصول۷. یکپارچگی با سرویس‌های بیرونی: پرداخت، پیامک، ایمیلیک BaaS ردیف‌های ۱ تا ۵ را می‌دهد. ردیف ۶ را تا حدی — با یک لایه‌ی قوانین یا فانکشن. ردیف ۷ را معمولاً نه، یا ناقص.این تقسیم‌بندی کل بحث است. چون در بیشتر اپلیکیشن‌هایی که واقعاً ساخته می‌شوند، ردیف‌های ۱ تا ۵ حدود هشتاد درصد کد بک‌اند را می‌گیرند و صفر درصد تمایز محصول را. هیچ کاربری اپ شما را به‌خاطر کیفیت اندپوینت GET /products انتخاب نمی‌کند. ولی نوشتنش، تستش، امن‌کردنش و نگه‌داشتنش وقت می‌برد.پس سؤال درست این نیست که «BaaS خوب است یا بد». این است: آن هشتاد درصد در پروژه‌ی من چقدر استاندارد است؟آزمون واقعی: سه سؤالاگر جواب هر سه «بله» بود، بک‌اند آماده احتمالاً برایتان جواب می‌دهد.۱. داده‌ام واقعاً جدول است؟اگر محصولتان چند موجودیت با رابطه‌های معمولی است — کاربر، سفارش، محصول، نوبت، مقاله — بله. اگر داده‌تان گراف سنگین است، سری‌زمانی با میلیون‌ها درج در ثانیه است، یا نیاز به کوئری‌های تحلیلی سنگین دارد، نه. این‌ها ابزار خودشان را می‌خواهند.۲. منطقم بعد از نوشتن اتفاق می‌افتد یا وسط آن؟منطقی که «قبل از ذخیره این را اعتبارسنجی کن» یا «بعد از ثبت سفارش موجودی را کم کن» باشد، در لایه‌ی قوانین اکثر BaaSها جا می‌شود. منطقی که چند سرویس را هماهنگ کند، تراکنش توزیع‌شده بخواهد، یا یک صف کاری چندمرحله‌ای باشد، نه.۳. حاضرم یک لایه را کنترل نکنم؟این سخت‌ترین سؤال است و بیشتر بحث‌ها از رویش رد می‌شوند. به بخش بعد می‌رسیم.چیزی که از دست می‌دهید و کسی رویش تأکید نمی‌کند: راه خروجهر BaaS شما را تا حدی قفل می‌کند. این ذاتی است، نه بدجنسی: وقتی مدل داده، دسترسی و منطق را داخل یک سرویس تعریف می‌کنید، آن تعریف‌ها به فرمت آن سرویس‌اند.سؤالی که باید قبل از شروع بپرسید، نه بعد از دو سال:> اگر فردا بخواهم بروم، دقیقاً چه چیزی را می‌توانم ببرم؟جواب‌ها خیلی فرق می‌کنند. بعضی سرویس‌ها فقط یک دامپ از رکوردها می‌دهند — یعنی داده را دارید ولی ساختار، رابطه‌ها و قوانین دسترسی را باید از صفر بسازید. بعضی مدل داده را هم می‌دهند. تعداد کمی قوانین را هم.معیار عملی‌ای که پیشنهاد می‌کنم: اگر خروجی سرویس به‌تنهایی برای بازسازی سیستم روی یک PostgreSQL خالی کافی نیست، شما داده دارید ولی راه خروج ندارید. این را روز اول تست کنید، وقتی هنوز چیزی برای از دست دادن ندارید.یک خروجی کامل یعنی سه چیز در یک بسته: مدل داده با همه‌ی روابط، خودِ رکوردها، و قوانین دسترسی. اگر هر کدام از این سه نبود، بازسازی سیستم در جای دیگر یعنی از نو نوشتنش. این را از هر سرویسی که بررسی می‌کنید بخواهید — از جمله از سرویسی که خودمان می‌سازیم.مورد خاص متن‌باز بودن هم همین‌جاست. یک سرویس متن‌باز و خودمیزبان‌شدنی (مثل Supabase یا Appwrite) این ریسک را حذف می‌کند، ولی هزینه‌اش را جابه‌جا می‌کند: حالا شما مسئول ارتقا، بکاپ، مانیتورینگ و امنیت آن هستید. اگر تیم DevOps دارید، معامله‌ی خوبی است. اگر ندارید، «متن‌باز است پس امن‌ام» یک آرامش کاذب است — کسی باید آن سرور را نگه دارد.لایه‌ای که برای تیم داخل ایران اضافه می‌شودتا اینجا هرچه گفتم جهانی بود. یک چیز اما مخصوص ماست، و عملاً گزینه‌ها را نصف می‌کند.Firebase از ایران باز نمی‌شود و کارت ایرانی نمی‌گیرد. Supabase متن‌باز است ولی اشتراک ابری‌اش هم همان مشکل پرداخت را دارد. راهکارهای رایج هرکدام هزینه‌ای دارند که معمولاً گفته نمی‌شود:واسطه و «نماینده‌ی رسمی»: حساب به نام شما نیست. اگر واسطه برود، سرویس هم می‌رود.خودمیزبانی روی سرور خارج: پینگ کاربر ایرانی بالا می‌رود و مسئولیت زیرساخت با شماست.خودمیزبانی روی سرور داخل: پینگ حل می‌شود، ولی همان بار عملیاتی سر جایش است.سرویس داخلی: پرداخت و دسترسی حل می‌شود، ولی سؤال «راه خروج» دوباره جدی می‌شود — و اینجا باید سخت‌گیر باشید. سرویسی که ما می‌سازیم، فیکارو، در همین دسته است؛ پس همان سخت‌گیری را روی ما هم اعمال کنید.نکته‌ای که می‌خواهم رویش تأکید کنم: تحریم دلیل خوبی برای پایین‌آوردن استانداردتان نیست. اینکه گزینه‌ها کم شده‌اند، سرویسی را که خروجی کامل نمی‌دهد قابل قبول نمی‌کند. اتفاقاً وقتی گزینه کم است، بند خروج مهم‌تر می‌شود، نه کم‌اهمیت‌تر.کِی اصلاً سراغش نرویدبرای اینکه این متن یک تبلیغ نباشد، صریح می‌گویم کجا BaaS جواب نمی‌دهد:وقتی محصول شما خودِ بک‌اند است. اگر می‌فروشید‌ش، نمی‌توانید اجاره‌اش کنید.وقتی الزام قانونی یا قراردادی دارید که داده جای مشخصی بماند و کنترل کامل دستتان باشد.وقتی بار شما واقعاً غیرعادی است. اگر مقیاستان جایی است که هر میلی‌ثانیه و هر کوئری را باید تیون کنید، لایه‌ی واسط دشمن شماست.وقتی تیمتان بک‌اندکار باتجربه دارد و پروژه بلندمدت است. آن‌وقت هشتاد درصدی که گفتم برایشان چند هفته است، نه چند ماه — و کنترل کامل می‌ارزد.و برعکس، جایی که واقعاً می‌درخشد: نمونه‌ی اولیه، MVP، پنل داخلی، اپ موبایلی که تیمش فقط فرانت‌اند دارد، و پروژه‌ای که باید قبل از جذب سرمایه یا قبل از یک ددلاین واقعی به دست کاربر برسد.جمع‌بندیبک‌اند آماده نه راه میان‌بر است نه اسباب‌بازی. یک معامله است: کدی که نمی‌نویسید در برابر کنترلی که ندارید.اگر داده‌تان جدول است، منطقتان دور نوشتن و خواندن می‌چرخد، و سرویس بتواند مدل و داده و قوانین را کامل به شما پس بدهد، معامله‌ی خوبی است. اگر هر کدام از این سه نبود، همان بک‌اند را بنویسید — و این شکست نیست، انتخاب درست است.این متن را تیم فیکارو نوشته؛ ما خودمان یک بک‌اند آماده‌ی ایرانی می‌سازیم، پس ذی‌نفعیم. سعی کردم معیارها طوری باشد که به ضرر خودمان هم بشود به کارشان برد — مخصوصاً بند «راه خروج»، که استانداردی است که خودمان باید جوابگویش باشیم.اگر خواستید این سه سؤال را جدی امتحان کنید، روی هر گزینه‌ای که بررسی می‌کنید یک پروژه‌ی کوچک واقعی بسازید و همان روز اول ازش خروجی کامل بگیرید. مقایسه‌ی خروجی‌ها گویاتر از مقایسه‌ی فهرست امکانات است، و تنها آزمونی است که بعداً نمی‌شود دوباره‌اش کرد.فیکاروفیکاروSat, 05 Sep 2026 14:42:27 +0330