فیکارو یا فایربیس؟ مقایسه‌ای که سه ردیفش را می‌بازیم

اگر تیمتان داخل ایران است و بین فیکارو و فایربیس مانده‌اید، این مقایسه‌ی نقطه‌به‌نقطه است — با جدولی که سه ردیفش را فیکارو می‌بازد. هر دو بک‌اند آماده‌اند و هر دو کار را از شما کم می‌کنند؛ ولی برای دو دنیای متفاوت ساخته شده‌اند و تفاوتشان بیشتر از آنکه فنی باشد، عملیاتی است.

فیکارو یا فایربیس؛ تفاوت اصلی در چیست؟

تفاوت اصلی فیکارو و فایربیس فنی نیست، عملیاتی است. فایربیس دیتابیس سندی (Firestore)، بلادرنگ، پوش نوتیفیکیشن و یک اکوسیستم بالغ می‌دهد، ولی از IP ایران بدون فیلترشکن باز نمی‌شود، کارت بانکی ایرانی نمی‌پذیرد و حساب‌های ایرانی سابقه‌ی مسدود شدن دارند. فیکارو PostgreSQL رابطه‌ای، API خودکار، موتور قوانین و مستندات OpenAPI می‌دهد، از داخل ایران بدون فیلترشکن باز می‌شود و پرداختش ساعتی و به تومان است. سه چیز را هم ندارد و در همین مقایسه با اسم آمده‌اند: بلادرنگ، پوش نوتیفیکیشن و تحلیل رفتار کاربر. پس معیار انتخاب روشن است: اگر هسته‌ی محصولتان بلادرنگ یا وابسته به نوتیفیکیشن است، جواب فایربیس است؛ اگر داده‌تان رابطه‌ای است و کاربرانتان داخل ایران‌اند، دسترسی و پرداخت تعیین‌کننده می‌شوند — و آن دو ردیف با هیچ امکان فنی جبران نمی‌شوند. مدل هزینه هم متفاوت است: فایربیس بر پایه‌ی مصرف حساب می‌کند و فیکارو ساعتی از کیف‌پول، بدون اشتراک ماهانه.

کجا فایربیس می‌برد

سه مورد، و هیچ‌کدام کوچک نیستند:

۱. بلادرنگ. فایربیس برای همین ساخته شد و هنوز در آن بهترین است. اگر محصولتان چت، ویرایش هم‌زمان، مکان‌نمای زنده یا بازی چندنفره است، داده باید بدون درخواست دوباره به کلاینت هُل داده شود. فیکارو امروز این را ندارد — نه ضعیف‌تر دارد، اصلاً ندارد؛ روی نقشه‌راه هست ولی تاریخی برایش اعلام نشده. اگر پروژه‌تان همین حالا شروع می‌شود و هسته‌اش بلادرنگ است، روی «در برنامه است» حساب نکنید.

۲. پوش نوتیفیکیشن. FCM رایگان است، روی اندروید و iOS کار می‌کند، و عملاً استاندارد صنعت است. فیکارو معادلی برایش ندارد. اگر اپتان به نوتیفیکیشن وابسته است، حتی اگر بقیه‌ی بک‌اند را جای دیگر ببرید، احتمالاً باز هم FCM را نگه می‌دارید.

۳. اکوسیستم. Crashlytics برای گزارش کرش، Remote Config برای تغییر رفتار اپ بدون انتشار نسخه، A/B تست، و Analytics — همه در یک کنسول و همه به هم وصل. اگر تیمتان روی این‌ها حساب باز کرده، مهاجرت یعنی از دست دادنشان یا سرِ هم کردن چند سرویس جدا.

اگر هیچ‌کدام از این سه مورد هسته‌ی محصولتان نیست، سؤال برمی‌گردد به همان چیزی که واقعاً هر روز آزارتان می‌دهد.

کجا فیکارو می‌برد

دسترسی و پرداخت. این یک ردیف در جدول نیست، شرط بقاست. سرویسی که کاربر نهایی شما نمی‌تواند به آن وصل شود، هرچقدر هم امکانات داشته باشد، بک‌اند محصول شما نیست. و صورتحسابی که نمی‌توانید بپردازید، دیر یا زود سرویس را می‌خواباند.

مدل داده‌ی رابطه‌ای. Firestore سندی است. برای داده‌ی تودرتو و ساده عالی است؛ ولی به‌محض اینکه «سفارش‌های این کاربر که وضعیتشان فلان است و مبلغشان بالای فلان» را بخواهید، در Firestore باید داده را تکرار کنید یا چند کوئری بزنید. PostgreSQL این را با یک join جواب می‌دهد. اگر داده‌تان رابطه‌ای است — فروشگاه، رزرو، CRM — این تفاوت هر هفته خودش را نشان می‌دهد.

منطق بدون کد. برای اعتبارسنجی، فیلد محاسبه‌شده یا تریگر شرطی، فایربیس شما را به Cloud Functions می‌فرستد: یعنی نوشتن کد، دیپلوی، و لاگ خواندن وقتی خراب شد. موتور قوانین فیکارو همین‌ها را در پنل می‌گیرد و قبل از اعمال، اجرای آزمایشی نشان می‌دهد.

تغییر اسکیما بدون دیپلوی. افزودن یا حذف فیلد فقط تغییر متادیتاست — بدون ALTER TABLE، بدون ری‌استارت، بدون build.

مستندات خودکار. OpenAPI و کالکشن Postman همان لحظه ساخته می‌شوند. فایربیس مستندات API ندارد چون API عمومی به آن شکل ندارد؛ SDK دارد.

یک مثال مشخص: بک‌اند یک فروشگاه کوچک

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

در فایربیس. Firestore سندی است، پس دو راه دارید. یا شناسه‌ی کاربر را داخل هر سفارش ذخیره می‌کنید و کوئری می‌زنید — که برای همین یک مورد کار می‌کند — یا اطلاعات کاربر را داخل سند سفارش تکرار می‌کنید تا لازم نباشد دو بار بخوانید. راه دوم رایج است و اسمش denormalization است. مشکلش وقتی پیدا می‌شود که کاربر نامش را عوض کند: حالا باید همه‌ی سفارش‌هایش را پیدا کنید و به‌روزرسانی کنید، وگرنه داده‌تان با خودش نمی‌خواند. برای فیلتر ترکیبی هم باید ایندکس مرکب تعریف کنید، و اگر یادتان برود، خطا را در زمان اجرا می‌گیرید نه موقع نوشتن.

در فیکارو. سفارش یک فیلد رابطه به کاربر دارد. کوئری همان درخواستی است که فیلتر و مرتب‌سازی و صفحه‌بندی را در پارامترهای خودش می‌گیرد، و دیتابیس با یک join جواب می‌دهد. تغییر نام کاربر یک‌جا اتفاق می‌افتد چون یک‌جا ذخیره شده.

این تفاوت به نفع فایربیس هم می‌تواند بچرخد: اگر داده‌تان واقعاً درختی است — مثلاً تنظیمات تودرتوی هر کاربر که همیشه یک‌جا خوانده می‌شود — مدل سندی طبیعی‌تر است و رابطه‌ای اضافه‌کاری می‌شود. سؤال درست «کدام بهتر است» نیست، «داده‌ی من کدام شکلی است» است.

هزینه چطور حساب می‌شود

بدون عدد، چون مدل هزینه‌ی هر دو به مصرف بستگی دارد و عددِ بی‌زمینه گمراه‌کننده است. ولی شکل هزینه فرق دارد و همین شکل است که تصمیم را عوض می‌کند:

فایربیس بر اساس عملیات حساب می‌کند — تعداد خواندن، نوشتن و حذف سند، به‌علاوه‌ی ترافیک و فضا. یعنی هزینه‌تان با الگوی کوئری‌نویسی‌تان بالا و پایین می‌شود؛ یک صفحه‌ی بد طراحی‌شده که هر بار صد سند می‌خواند، در صورتحساب دیده می‌شود. مزیتش این است که پروژه‌ی کم‌مصرف واقعاً کم‌هزینه است.

فیکارو ساعتی از کیف‌پول کسر می‌کند: پروژه روشن است و هزینه دارد، مستقل از اینکه چند کوئری زده‌اید. پیش‌بینی‌پذیرتر است و صورتحساب غافلگیرکننده ندارد، ولی پروژه‌ای که تقریباً هیچ ترافیکی ندارد هم صفر نمی‌شود.

و یک تفاوت که ربطی به عدد ندارد: صورتحساب فایربیس را باید بتوانید بپردازید. صفحه‌ی قیمت‌گذاری نشان می‌دهد هر مبلغ شارژ، پروژه را چند روز روشن نگه می‌دارد.

پس کدام؟

• اپ بلادرنگ یا وابسته به پوش می‌سازید → فایربیس. حتی با همه‌ی دردسر دسترسی و پرداخت.
• کاربرانتان خارج از ایران‌اند و پرداخت ارزی مشکلی نیست → فایربیس یا Supabase.
• داده‌تان رابطه‌ای است و کاربرانتان داخل ایران → فیکارو.
• مطمئن نیستید → با فیکارو شروع کنید و خروجی کامل داده را امتحان کنید. اگر هر لحظه بتوانید همه‌چیز را بیرون بکشید، انتخاب اولیه تصمیم برگشت‌ناپذیری نیست.

برای دیدن بقیه‌ی گزینه‌ها — از Appwrite خودمیزبان تا سرویس‌های ابری خارجی — جایگزین فایربیس در ایران هشت گزینه را کنار هم گذاشته است. اگر می‌خواهید ببینید فیکارو در عمل چه شکلی است، قالب‌های آماده بک‌اندهای واقعی و کارکننده‌اند که می‌توانید مبنای پروژه‌تان کنید.

سوالات متداول

می‌شود بخشی از پروژه روی فایربیس بماند و بخشی روی فیکارو باشد؟

بله و در عمل رایج است. الگوی متداول این است که داده و احراز هویت به فیکارو می‌آید و FCM برای پوش نوتیفیکیشن روی فایربیس می‌ماند، چون FCM جداگانه هم قابل استفاده است. هر دو REST و توکن‌محورند، پس کنار هم بودنشان کار خاصی نمی‌برد.

مهاجرت داده از Firestore به فیکارو چقدر طول می‌کشد؟

بخش سختش انتقال داده نیست، بازطراحی مدل است: Firestore سندی است و فیکارو رابطه‌ای، پس داده‌ی تودرتو باید به جدول و رابطه ترجمه شود. برای یک پروژه‌ی متوسط معمولاً چند روز کار فکری است و بعدش خروجی JSON فایربیس با ابزار ورود داده منتقل می‌شود.

فیکارو بلادرنگ ندارد؛ برای اپلیکیشنی که به‌روزرسانی زنده می‌خواهد چه کنم؟

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

هزینه‌ی فیکارو در برابر فایربیس چطور حساب می‌شود؟

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