سوپابیس و ریل‌وی رقیب هم نیستند؛ دو لایه از یک پشته‌اند که با هم یک محصول کوچک را از ایده به انتشار می‌رسانند. سوپابیس پشت صحنه محصول را می‌سازد: پایگاه داده، احراز هویت کاربران، ذخیره فایل و توابع سمت سرور. ریل‌وی همان محصول را از مخزن گیت می‌سازد، منتشر می‌کند و محیط آزمایشی جدا در اختیار شما می‌گذارد.
تقسیم کار: هر سرویس چه بخشی از پروژه را می‌گیرد
| لایه پروژه | سرویس مناسب‌تر | توضیح کوتاه |
|---|---|---|
| پایگاه داده و احراز هویت | سوپابیس | بک‌اند مدیریت‌شده روی Postgres با رابط مدیریت |
| ساخت و انتشار برنامه | ریل‌وی | ساخت خودکار از مخزن گیت و مدیریت متغیرها |
| محیط آزمایشی هر شاخه | ریل‌وی | محیط جدا با متغیرهای محیطی خودش |
| توابع سمت سرور | سوپابیس | توابع لبه برای منطق نزدیک به داده |
| کار زمان‌بندی‌شده و صف | هر دو، با احتیاط | به معماری محصول شما بستگی دارد |
سوپابیس: بک‌اند مدیریت‌شده برای شروع سریع
منطق کار سوپابیس این است که شما فقط جدول و منطق بنویسید و نگهداری سرور را به عهده نگیرید. هر پروژه با یک پایگاه داده Postgres و رابط مدیریت شروع می‌شود و روی همان جدول‌ها رابط برنامه‌نویسی خودکار ساخته می‌شود. احراز هویت کاربران، ذخیره‌سازی فایل و به‌روزرسانی زنده داده هم کنار همان پایگاه داده قرار می‌گیرند تا برای هر بخش مجبور نباشید سرویس جدا بخرید.
- پایگاه داده Postgres مدیریت‌شده
- احراز هویت کاربران با چند روش ورود
- ذخیره‌سازی فایل برای تصاویر و پیوست‌ها
- رابط برنامه‌نویسی خودکار روی جدول‌ها
- به‌روزرسانی زنده داده برای اپلیکیشن
سیاست دسترسی را جدی بگیرید
بزرگ‌ترین اشتباه در کار با بک‌اند مدیریت‌شده، باز گذاشتن جدول‌ها است. اگر سرویس شما به کاربران واقعی سرویس می‌دهد، پیش از هر چیز سیاست دسترسی سطح سطر را روشن کنید تا هر کاربر فقط داده خودش را ببیند. این کار را همان روز اول انجام دهید، نه بعد از انتشار.
alter table public.notes enable row level security;
create policy notes_owner_read on public.notes
for select using (auth.uid() = user_id);
create policy notes_owner_write on public.notes
for insert with check (auth.uid() = user_id);این نمونه شکل کار را نشان می‌دهد: اول محافظت جدول را روشن می‌کنیم، بعد برای هر عملیات سیاست می‌نویسیم. قاعده کلی این است که هیچ جدولی بدون سیاست دسترسی در محیط تولید باقی نماند؛ نام دقیق توابع و ستون‌ها را با مستندات روز سرویس تطبیق دهید.
مهاجرت‌ها را تکرارپذیر نگه دارید
اگر جدول‌ها را با کلیک در داشبورد بسازید، بازسازی محیط آزمایشی و انتقال تغییرها به تولید سخت می‌شود. هر تغییر ساختاری را در فایل مهاجرت بنویسید و در مخزن نگه دارید؛ این کار سه چیز می‌دهد: تاریخچه تغییرات داده، امکان ساخت دوباره محیط و بازبینی ساختار پیش از اجرا. قبل از تغییر یک جدول پرکار، یک پشتیبان تازه بگیرید و بدانید بازگشت به عقب چه شکلی است.
ریل‌وی: استقرار و محیط‌های جدا
ریل‌وی کار ساخت و انتشار را از مخزن گیت می‌گیرد: کد خوانده، ساخته و منتشر می‌شود و متغیرهای محیطی از داشبورد مدیریت می‌شوند. برای تیمی که می‌خواهد بدون درگیر شدن با تنظیمات سرور منتشر کند، همین مدل کافی است و می‌توان پایگاه داده مدیریت‌شده را هم در همان پروژه ساخت.
- استقرار خودکار از مخزن گیت
- پشتیبانی از زبان‌ها و چارچوب‌های مرسوم
- پایگاه داده مدیریت‌شده کنار سرویس
- مدیریت متغیرهای محیطی و دامنه
- گزارش سرویس و مصرف منابع در داشبورد
محیط آزمایشی برای هر شاخه
یکی از سودمندترین قابلیت‌ها، ساخت محیط جدا برای شاخه‌های جدید است. تغییر را روی محیط آزمایشی تست می‌کنید، متغیرهای همان محیط جدا می‌ماند و بعد از بررسی، تغییر را روی نسخه اصلی منتشر می‌کنید. بدون این تفکیک، هر تغییر کوچک روی داده و کاربران واقعی یک ریسک است.
مسیر راه‌اندازی یک محصول کوچک
- مخزن گیت را آماده کنید و نمونه متغیرهای محیطی را بنویسید
- پروژه سوپابیس را بسازید و جدول‌های اصلی را با مهاجرت تکرارپذیر بسازید
- سیاست دسترسی سطح سطر را برای هر جدول بنویسید
- احراز هویت و ذخیره‌سازی فایل را به رابط برنامه متصل کنید
- محیط ریل‌وی را به مخزن وصل کنید و محیط آزمایشی بسازید
- پس از تست، نسخه اصلی را با متغیرهای محیط تولید منتشر کنید
محدودیت‌ها و مرزهای این ترکیب
این ترکیب برای محصول کوچک و متوسط و تیم کوچک عالی است، اما حد و مرز دارد. کارهای تحلیل سنگین، حجم بالای نوشتن داده یا منطق پیچیده سمت سرور دیر یا زود به معماری اختصاصی‌تر نیاز پیدا می‌کند. هر دو سرویس ابری‌اند؛ اگر مقررات داخلی سازمان شما جای داده را تعیین می‌کند، این محدودیت را پیش از شروع روشن کنید. به‌جای حدس زدن درباره سقف‌ها، فهرست محدودیت‌های پلن خود را در داشبورد سرویس بخوانید و برای رشد داده یک نقشه ذخیره‌سازی و پشتیبان‌گیری داشته باشید.
فعال‌سازی و نام حساب
دسترسی هر دو سرویس روی ایمیل خودتان فعال می‌شود؛ پروژه، پایگاه داده، سرویس منتشرشده و متغیرها در حساب خودتان می‌ماند و لازم نیست فضای کاری را جابه‌جا کنید. پس از ثبت سفارش و تأیید شرایط، فعال‌سازی انجام می‌شود و اگر ارائه‌دهنده بازبینی لازم داشته باشد، بازه تحویل در روزهای کاری اعلام می‌شود. پشتیبانی سفارش تا پایان اعتبار پلن همراه شماست.
