پارادایس کداستودیوی نرم‌افزار
بازگشت به مقالات
بک‌اند۳۰ دی ۱۴۰۴16 دقیقه مطالعه

دیپلوی روی Vercel و معماری بدون سرور اختصاصی

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

VercelServerlessDevOpsNext.jsاستقرار

علی مرتضوی

بنیان‌گذار پارادایس کد

تغییر پارادایم: از سرور دائمی به اجرای رویدادمحور

سال‌ها مدل رایج این بود: یک VPS یا سرور اختصاصی، نصب Node، اجرای PM2، و نگهداری مداوم. امروز برای بسیاری از وب‌اپلیکیشن‌های محصول‌محور، پلتفرم‌هایی مثل Vercel اجرای توابع، CDN، پیش‌نمایش PR و pipeline استقرار را یکجا می‌دهند. این تغییر فقط هاستینگ نیست؛ معماری شما باید statelessتر، کش‌محورتر و تحمل‌پذیر نسبت به cold start باشد.

مزیت اصلی serverless برای تیم‌های کوچک و متوسط، کاهش بار عملیاتی است. شما کمتر درگیر patch امنیتی سیستم‌عامل، تنظیم nginx و مقیاس دستی می‌شوید. در عوض، هزینه و پیچیدگی به لایه application منتقل می‌شود: مدیریت اتصال دیتابیس، محدودیت زمان اجرا، و طراحی jobهای پس‌زمینه.

برای استودیوهایی مثل پارادایس کد که محصولات متنوع تحویل می‌دهند، Vercel گزینه پیش‌فرض خوبی برای فرانت Next.js است؛ اما همیشه باید بپرسیم آیا بک‌اند هم باید روی همین پلتفرم باشد یا جدا مستقر شود.

چه زمانی Vercel انتخاب درستی است

اگر محصول شما عمدتاً Next.js است، ترافیک متغیر دارد، نیاز به preview environment برای هر PR دارید، و تیم DevOps اختصاصی ندارید، Vercel معمولاً انتخاب منطقی است. سایت‌های مارکتینگ، فروشگاه‌های متوسط، پنل‌های مدیریت با ترافیک قابل پیش‌بینی، و MVPهای سریع در این دسته قرار می‌گیرند.

اما اگر workload شما پردازش سنگین طولانی، WebSocket پایدار با اتصال زیاد، یا وابستگی به سرویس‌های محلی خاص دارد، مدل serverless محدودیت‌های جدی دارد. در این موارد ترکیب Vercel برای فرانت و یک سرویس container یا VPS برای بک‌اند بهتر عمل می‌کند.

هزینه را فقط با اشتراک ماهانه قضاوت نکنید. هزینه واقعی شامل زمان تیم، خطای استقرار، downtime و ابزارهای جانبی است. برای بسیاری از تیم‌ها، سرعت iterate در Vercel ارزش هزینه بالاتر را دارد.

طراحی بک‌اند سازگار با serverless

در معماری serverless، هر درخواست ممکن است در یک instance تازه اجرا شود. پس اتصال دیتابیس باید pooled یا serverless-friendly باشد. استفاده مستقیم از connection سنتی PostgreSQL در تابع بدون pool می‌تواند به اتمام connection منجر شود.

عملیات طولانی را از مسیر HTTP جدا کنید. آپلود بزرگ، تولید PDF، یا پردازش تصویر را به queue و worker بسپارید. route handler در Next.js برای شروع job و برگرداندن شناسه پیگیری مناسب است؛ نه اجرای چند دقیقه‌ای داخل همان request.

state را در حافظه process نگه ندارید. session، cache و rate limit باید در Redis، دیتابیس یا سرویس managed باشند. فراموش کردن این اصل در serverless به باگ‌های وابسته به instance منجر می‌شود.

متغیرهای محیطی، امنیت و محیط‌های چندگانه

در Vercel، environment variableها را برای Production، Preview و Development جدا تنظیم کنید. کلیدهای پرداخت، توکن API و رشته اتصال دیتابیس نباید در previewهای عمومی PR در دسترس باشند مگر با سیاست مشخص.

برای محصولات ایرانی، گاهی محدودیت دسترسی به برخی سرویس‌های بین‌المللی وجود دارد. قبل از قفل کردن معماری روی یک vendor، بررسی کنید CDN، DNS و سرویس‌های third-party از نظر دسترسی و تأخیر برای کاربر هدف قابل قبول هستند.

secrets را در repo commit نکنید. از rotation دوره‌ای کلیدها و audit دسترسی تیم استفاده کنید. استقرار امن بخشی از معماری است، نه کار بعد از تحویل.

استراتژی CI/CD و پیش‌نمایش محصول

یکی از قوی‌ترین ویژگی‌های Vercel، preview deployment برای هر pull request است. این قابلیت وقتی ارزشمند است که تیم محصول و طراحی واقعاً در review شرکت کنند. برای این کار، preview باید به دیتابیس seed شده یا محیط staging ایزوله وصل شود، نه production.

قرارداد branch را مشخص کنید: main برای production، develop یا staging برای تست یکپارچه. از protection rule روی main استفاده کنید تا deploy ناخواسته رخ ندهد.

تست smoke بعد از deploy خودکار را جدی بگیرید: health check، login، یک مسیر خرید یا ثبت محتوا. خطای استقرار خاموش می‌تواند گران‌تر از downtime کوتاه باشد.

اجتناب از vendor lock-in و بقای معماری

قفل شدن روی Vercel به معنای استفاده نکردن از آن نیست؛ به معنای طراحی آگاهانه است. Next.js را طوری بنویسید که وابستگی به edge-only APIهای اختصاصی حداقل باشد. لایه دامنه و سرویس را از transport جدا کنید تا مهاجرت به Node standalone یا Docker ممکن بماند.

لاگ و مانیتورینگ را به ابزار مستقل مثل Sentry یا Axiom وصل کنید تا با تغییر پلتفرم، دید خود را از دست ندهید. Infrastructure as Code برای تنظیمات حیاتی، حتی در managed platform، توصیه می‌شود.

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

دانش و مقالات

نیاز به اجرای همین مفاهیم در محصولتان دارید؟

پارادایس کد از مشاوره تا پیاده‌سازی کامل کنار شماست.

درخواست همکاری