انتخاب هاستی که نمی‌تواند دسترسی‌ام را پس بگیرد

زمینه

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

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

گزینه‌های بررسی‌شده

Cloudflare Pages. انتخاب اولم بود و سر یک واقعیت ساده غلط از آب درآمد: Pages اصلاً Next.js را در حالت سرور اجرا نمی‌کند. @cloudflare/next-on-pages در npm دیپرکیت شده و خودش کاربر را به آداپتور OpenNext ارجاع می‌دهد.

Cloudflare Workers با @opennextjs/cloudflare. واقعاً توانمند است — App Router، RSC، Server Actions، ISR و 'use cache'. سه مشکل دارد. پلن رایگان برای هر ریکوئست فقط ۱۰ میلی‌ثانیه CPU می‌دهد که رندر سمت سرور React در آن جا نمی‌شود، و سقف حجم باندل ورکر را روی ۳ مگابایت gzip شده می‌گذارد، در حالی که ورکرهای واقعی OpenNext معمولاً بین ۳٫۱ تا ۳٫۴ درمی‌آیند. دامنه‌ی *.workers.dev داخل ایران با DNS به 10.10.34.36 منحرف شده؛ یعنی نمی‌توانستم نمونه‌کار خودم را از شهر خودم باز کنم. و اینکه اصلاً می‌شود از اینجا اکانت ساخت و پولش را داد یا نه، در هیچ جهتی قابل تأیید نبود — هیچ منبعی نه تأییدش کرد نه ردش.

Cloudflare Workers با vinext. پیشنهاد فعلی خودِ Cloudflare. با یک خط از جدول پشتیبانی‌اش رد شد: next/font فقط «بارگذاری از CDN در زمان اجرا؛ بدون self-host و بدون subset» را پشتیبانی می‌کند. Vazirmatn را دقیقاً به این دلیل خودم هاست می‌کنم که CDN گوگل‌فونتس از ایران قابل اتکا نیست. خودش هم می‌گوید هنوز آماده‌ی production نیست.

Liara با بیلد داکری standalone. یک هاست ایرانی. در دسترس است، می‌شود پولش را داد، و قبلاً از همین مسیر منتشر کرده‌ام.

تصمیم

Liara، با output: 'standalone'، بیلد چندمرحله‌ای روی node:22-alpine و یوزر non-root.

استدلال تعیین‌کننده پرفورمنس نیست، در دسترس بودن است. پلتفرمی که ممکن است سر تحریم مرا از دست بدهد، یک نقطه‌ی شکست واحد است که زیر هر چیز دیگری که می‌سازم نشسته. انتخاب پلتفرم مد روز و فهمیدن این موضوع در بدترین لحظه، از پذیرفتن یک گزینه‌ی کندتر همین حالا بدتر است.

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

هزینه‌هایی که پذیرفتم

• لتنسی بین‌المللی. هاست ایرانی برای کسی که از برلین یا سان‌فرانسیسکو نگاه می‌کند کندتر است. با static-first و سبک نگه‌داشتن سایت جبرانش کرده‌ام؛ هزینه بیشتر روی TTFB می‌افتد تا حجم، و بعداً می‌شود بدون دست‌زدن به اپلیکیشن یک CDN جلویش گذاشت.
• بدون edge compute. کلاً از امکانات پایه‌ی پلتفرم صرف‌نظر می‌کنم. برای یک نمونه‌کارِ از پیش رندرشده امروز هزینه‌ای ندارد؛ برای محصولی با ترافیک واقعی محدودیت جدی‌ای است.
• کانتینری که خودم می‌گردانمش. حجم ایمیج، CVEهای ایمیج پایه و پین‌کردن نسخه‌ی Node حالا با من است. این هزینه‌ی جاری است، نه یک راه‌اندازی یک‌باره.

صادق باشم: دارم از یک محدودیت فضیلت می‌سازم. اگر می‌شد از اینجا روی edge جهانی دیپلوی کنم، احتمالاً همان کار را می‌کردم.

نتیجه

از دستگاه خودم دیپلوی می‌شود، از شهر خودم باز می‌شود، روی زیرساختی که هیچ تغییر سیاستی در جای دیگر دنیا نمی‌تواند از من بگیرد. معماری عمداً قابل جابه‌جایی است: خود اپلیکیشن هیچ آداپتوری ندارد، پس رفتن روی هر هاست Node دیگری سه فایل کار دارد.

محیط، وسط ساختن همین پروژه استدلال را برایم تکرار کرد. موقع راه‌اندازی ریپو، curl به CDN فونت از همین دستگاه در لایه‌ی TLS شکست خورد، در حالی که رجیستری npm بی‌مشکل جواب می‌داد — پس تایپ‌فیس لاتین را از دل یک tarball روی npm بیرون کشیدم. این یک سناریوی فرضی درباره‌ی در دسترس بودن نیست؛ روال هر روز است.

چه چیزی را عوض می‌کردم

امکان‌سنجی را اول انجام می‌دادم. یک معماری کامل روی Cloudflare طراحی کردم — آداپتور، کانفیگ wrangler، یک گیت بیلد برای حجم ورکر، و یک فایل _headers برای جایگزینی هدرهای امنیتی‌ای که بی‌سروصدا از صفحات از پیش رندرشده حذف می‌شوند — قبل از اینکه ثابت کنم اصلاً می‌توانم نتیجه‌اش را از تهران باز کنم. یعنی یک ساعت طراحی دور ریخته شد چون یک تست ده‌دقیقه‌ای انجام نشده بود.

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