انتخاب میان Vercel و Cloudflare Workers را باید از مسیر داده و نیاز اجرای برنامه شروع کرد. نام Edge به‌تنهایی تضمین پاسخ سریع نیست. اگر کد نزدیک کاربر اجرا شود ولی برای هر درخواست چند بار با پایگاه داده دور ارتباط بگیرد، زمان رفت‌وبرگشت همچنان وارد پاسخ می‌شود. مقاله قبلی Cloudflare را همیشه ارزان‌تر و سریع‌تر و Vercel را انتخاب قطعی Next.js معرفی می‌کرد. چنین نتیجه‌ای بدون نوع برنامه، مصرف و محیط داده قابل دفاع نیست.
این دو نام نیز دقیقاً یک لایه یکسان را توصیف نمی‌کنند. Vercel یک پلتفرم استقرار با مجموعه‌ای از امکانات ساخت، توزیع و اجرای برنامه است. Workers محیط اجرای برنامه در زیرساخت Cloudflare است و معمولاً کنار سرویس‌های دیگر این پلتفرم به کار می‌رود. در تصمیم فنی باید مجموعه لازم برای محصول را مقایسه کنید؛ قیمت یا قابلیت یک جزء را جای هزینه کل معماری نگذارید.
سه مکان متفاوت را روی کاغذ مشخص کنید
کاربر، محل اجرای کد و محل داده سه نقطه مستقل‌اند. برای یک صفحه عمومی cache شده، فاصله کاربر تا نقطه توزیع محتوا مهم است. برای یک درخواست که موجودی را می‌خواند و سپس سفارش را ثبت می‌کند، فاصله کد تا پایگاه داده هم اهمیت دارد. یک تصویر آموزشی ساده از این مسیر، اغلب از شمارش تعداد مرکزهای داده مفیدتر است. تعداد بیشتر نقاط حضور به خودی خود نشان نمی‌دهد درخواست شما کجا اجرا می‌شود.
در نمونه فرضی فروشگاه، API ابتدا مشتری را می‌خواند، بعد موجودی را بررسی می‌کند و سپس تخفیف را به دست می‌آورد. اگر این سه درخواست پشت سر هم به یک پایگاه داده دور بروند، نزدیکی API به مرورگر همه تأخیر را جبران نمی‌کند. شاید اجرای کد نزدیک داده، ادغام خواندن‌ها یا cache کردن بخش عمومی مناسب‌تر باشد. انتخاب محل اجرا باید بر اساس همین الگوی ارتباط انجام شود.
داده شخصی و داده مشترک نیز نیاز یکسان ندارند. متن معرفی محصول برای همه یکسان است و می‌توان آن را جدا cache کرد. پاسخ شامل سفارش‌های یک مشتری به مجوز او وابسته است. قراردادن همه این اطلاعات در یک پاسخ با یک سیاست cache، خطر و هزینه را بالا می‌برد. پیش از انتخاب سرویس، پاسخ‌ها را به کلاس‌های داده تقسیم کنید و مسئولیت تازه‌سازی و کنترل دسترسی هر کلاس را بنویسید.
Runtime و سازگاری کتابخانه‌ها
Runtime تعیین می‌کند کدام APIها و کتابخانه‌ها قابل استفاده‌اند. Web Standard APIها مانند Request و Response برای کد قابل حمل مفیدند، اما بسته‌های npm ممکن است به امکانات خاص Node.js یا افزونه بومی وابسته باشند. راهنمای Node.js Compatibility در Workers وضعیت پشتیبانی و نیاز تنظیم nodejs_compat را توضیح می‌دهد. فعال کردن یک flag را تضمین اجرای تمام بسته‌ها ندانید.
در Vercel نیز باید Runtime واقعی Function را از شبکه توزیع محتوا تفکیک کنید. مرجع Runtimeهای Vercel Functions و صفحه Edge Runtime وضعیت و محدودیت‌های همان محیط را مشخص می‌کنند. با توجه به تحول این خدمات، از مثال قدیمی یک framework درباره تنظیم Edge برای نتیجه گرفتن درباره تمام Functionهای امروز استفاده نکنید. نسخه framework و مدل اجرای پلتفرم باید با هم سازگار باشند.
فهرست وابستگی‌ها را بر اساس اهمیت مرتب کنید. کتابخانه تولید PDF، درایور پایگاه داده و ابزار پردازش تصویر معمولاً نیازهای بیشتری از تابع ساده تبدیل رشته دارند. اگر یک قابلیت حیاتی در محیط مورد نظر اجرا نمی‌شود، راه‌حل ممکن است سرویس جداگانه باشد؛ این سرویس هزینه، latency و نقطه شکست تازه اضافه می‌کند. مقایسه را پس از افزودن این اجزا دوباره انجام دهید، نه فقط بر اساس نمونه ساده آغاز پروژه.
در بازبینی فعلی، صفحه رسمی Vercel مهاجرت از Edge Runtime به Node.js را برای عملکرد و قابلیت اتکا توصیه می‌کند و می‌گوید از Next.js 16.3 تنظیم runtime = 'edge' پشتیبانی نمی‌شود. بنابراین مقایسه امروز را باید با Vercel Functions و Runtime مورد نیاز پروژه انجام داد؛ یک راهنمای قدیمی درباره Edge، نسخه مناسبی برای استقرار جدید نیست. این توضیح، وضعیت اعلام‌شده همان پلتفرم است و نتیجه بنچمارک مستقل درباره تمام پروژه‌ها محسوب نمی‌شود.
محل اجرا را نزدیک نیاز داده انتخاب کنید
Workers بر پایه isolateها اجرا می‌شود؛ توضیح رسمی معماری Workers به این مدل مربوط است. با این حال متغیر حافظه یک اجرای برنامه را محل پایدار نگهداری سبد یا نشست فرض نکنید. تغییر محل اجرا یا چرخه عمر instance می‌تواند آن مقدار را از بین ببرد. داده پایدار باید در سرویس ذخیره‌سازی مناسب قرار بگیرد و قرارداد دسترسی آن روشن باشد.
Cloudflare قابلیت Placement برای تطبیق محل اجرای برخی بارهای کاری با دسترسی به backend دارد. راهنمای Placement شرایط و روش تنظیم را توضیح می‌دهد. در Vercel نیز تنظیم region برای Functions به محل اجرای کد مربوط است. این امکانات را باید بر اساس الگوی درخواست خودتان بخوانید؛ فعال کردن یک تنظیم، تمام منابع بیرونی را نزدیک نمی‌کند.
اگر پایگاه داده در یک region مشخص است، دسترسی نوشتن را جدا از توزیع خواندن عمومی بررسی کنید. داده‌ای که به‌ندرت تغییر می‌کند ممکن است از cache بهره ببرد، ولی ثبت سفارش باید به منبع معتبر برسد. Replica نیز الزاماً آخرین نوشتن را فوراً نشان نمی‌دهد. برای تجربه‌ای مانند نمایش سفارش بلافاصله پس از ثبت، سیاست خواندن باید با مدل consistency سرویس داده هماهنگ باشد.
Cache هزینه کمتر را مشروط می‌کند
Cache تنها زمانی مفید است که پاسخ واقعاً قابلیت استفاده دوباره داشته باشد. کلید cache باید عوامل مؤثر بر پاسخ را لحاظ کند؛ زبان، پارامتر جست‌وجو یا نسخه محتوای عمومی نمونه‌اند. برای پاسخ شخصی، تصمیم باید با احتیاط و شناخت مجوز انجام شود. استفاده از URL یکسان برای دو کاربر، دلیل مشترک بودن پاسخ نیست. cookie یا header درخواست می‌تواند معنای آن را تغییر دهد.
زمان اعتبار و ابطال را به چرخه محصول وصل کنید. اگر قیمت تغییر می‌کند، صفحه باید مطابق سیاست فروش تازه شود. اگر سیاست ارسال ویرایش می‌شود، تحریریه باید زمان دیده شدن تغییر را بداند. یک cache بدون مسیر ابطال ممکن است در نمایش سریع باشد ولی اطلاعات قدیمی تحویل دهد. هزینه کمتر اجرای کد، به‌تنهایی جبران‌کننده سفارش اشتباه یا پاسخ غیرقابل اعتماد نیست.
هزینه را با سناریو محاسبه کنید
صورت‌حساب شامل فقط تعداد درخواست نیست. CPU، حافظه، انتقال داده، ذخیره‌سازی، build و سرویس‌های جانبی می‌توانند در مدل مربوط به هر سرویس دخیل باشند. قیمت‌گذاری Workers و قیمت‌گذاری Functions مرجع ارقام و حدود جاری‌اند. در این مطلب عدد ثابتی برای ارزان‌تر بودن یکی درج نشده، چون ترکیب مصرف و طرح انتخابی نتیجه را تغییر می‌دهد.
سه سناریوی مصرف بنویسید: وضعیت معمول محصول، رشد قابل انتظار و رخداد فشار غیرعادی. مقدارهای این سناریو را از اطلاعات واقعی محصول یا فرض صریح طراحی بگیرید؛ آن‌ها را آمار مشتری واقعی معرفی نکنید. مشخص کنید کدام مصرف قابل کنترل است و در صورت افزایش چه محدودیتی اعمال می‌شود. یک طرح رایگان برای آشنایی اولیه، بودجه پایدار محصول تجاری را ثابت نمی‌کند.
هزینه تیم را هم لحاظ کنید. انتقال پروژه‌ای که انتشار، گزارش خطا و دسترسی‌ها در آن جا افتاده است زمان می‌گیرد. اگر تیم با یک ابزار آشناست، این آشنایی مزیت اجرایی دارد؛ اگر وابستگی به ابزار مانع قابلیت لازم شده، ادامه دادن هم هزینه دارد. مقایسه صادقانه باید هزینه تغییر و هزینه ماندن را با شرح کار مشخص بیان کند، نه فقط یک جدول قیمت ماهانه.
استقرار و عیب‌یابی بخشی از انتخاب‌اند
Preview Environment برای مرور تغییرات مفید است، ولی باید از داده Production جدا شود. نسخه آزمایشی نباید به خاطر یک تنظیم مشترک، سفارش واقعی ثبت کند یا پیام واقعی بفرستد. محیط‌ها را با نام روشن، رازهای جدا و دسترسی محدود تعریف کنید. این قرارداد باید در هر دو پلتفرم بررسی شود و وجود یک دکمه preview جای آن را نمی‌گیرد.
برای پشتیبانی، شناسه درخواست و گزارش خطای قابل جست‌وجو لازم است. اگر یک عملیات میان Function و backend تقسیم شده، باید بتوان مسیر آن را دنبال کرد. اطلاعات شخصی و رازها را وارد log نکنید. در رخداد خطا، تیم باید بداند مشکل در کد، دسترسی به داده یا محدودیت سرویس است. محدودیت‌های Workers بخشی از این قرارداد عملیاتی‌اند؛ حدود مشابه محیط انتخابی Vercel را نیز در تصمیم ثبت کنید.
برای Next.js، سازگاری adapter و قابلیت‌های مورد استفاده را جدا بخوانید. نیاز به Streaming، cache و به‌روزرسانی داده را با محیط اجرا تطبیق دهید. مقاله Partial Prerendering و Cache Components به این مرزها مربوط است. برای خودکارسازی انتشار نیز گردش کار CI/CD ادامه مناسب‌تری از اتکا به راه‌اندازی دستی است.
پیش از تصمیم نهایی، یک مسیر نماینده محصول را انتخاب کنید و قرارداد آن را بنویسید: وابستگی ضروری، محل داده، نوع cache، نیاز استقرار و راه بازگشت. انتخاب را با همان قرارداد ثبت کنید. ممکن است یک سایت محتوایی و یک API نوشتنی در یک سازمان پاسخ‌های متفاوتی داشته باشند؛ این تفاوت زمانی قابل نگهداری است که دلیل و مسئول هر بخش روشن باشد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!