انتشار یک سایت ایستای Next.js روی Cloudflare Workers
چرا این سایت یک خروجی کاملاً ایستای Next.js است که یک Worker کوچک سرو می‌کند: صفحه‌های سریع، هزینهٔ نزدیک به صفر، محافظت سمت سرور از بخش مدیریت و هدرهای امنیتی.
3 دقیقه مطالعهGryffin Forge
این وب‌سایت با Next.js و React ساخته شده، اما هیچ سرور Node.js در هیچ جا اجرا نمی‌شود. هر صفحهٔ عمومی هنگام ساخت به HTML ایستا تبدیل می‌شود و از لبهٔ شبکهٔ Cloudflare سرو می‌شود. یک Worker کوچک همان چند کاری را انجام می‌دهد که واقعاً به سرور نیاز دارند. دلیلش و اینکه اجزا چطور کنار هم قرار می‌گیرند در ادامه آمده.
اول ایستا
تقریباً همه‌چیز در یک سایت نمونه‌کار و دمو محتوای ثابت است: توضیح دموها، مقاله‌ها، مطالعه‌های موردی، صفحه‌های ابزار. هیچ‌کدام برای هر بازدیدکننده تغییر نمی‌کند؛ پس ساختنشان در هر درخواست فقط تأخیر و هزینه اضافه می‌کند، بی‌هیچ فایده‌ای.
با output: "export"، Next.js هر مسیر را — از جمله مسیرهای پویا مثل /demos/[slug] که با generateStaticParams شمرده می‌شوند — به فایل‌های HTML ساده تبدیل می‌کند. نتیجه:
- نمایش اولیهٔ سریع — HTML کامل می‌رسد، بدون زمان ساخت روی سرور.
- کمترین جاوااسکریپت — اجزای سمت سرور هیچ کد سمت کاربری نمی‌فرستند؛ فقط بخش‌های تعاملی (فیلترها، ماشین‌حساب‌ها، نمایشگر دمو) فعال می‌شوند.
- هزینهٔ اجرای نزدیک به صفر — فایل‌های ایستا روی Cloudflare از کش سرو می‌شوند.
- حالت‌های شکست ساده — هیچ سرور برنامه‌ای نیست که از کار بیفتد.
جایی که هنوز سرور لازم است
سه چیز نمی‌توانند ایستا باشند:
- بخش مدیریت باید پیش از ارسال هر محتوایی محافظت شود.
- آمار و گزارش خطا به یک نقطهٔ پایانی برای دریافت نیاز دارند.
- قابلیت‌های تجاری باید سمت سرور رد شوند، نه فقط پنهان.
یک Worker فقط برای /admin و /api/* جلوی فایل‌های ایستا قرار می‌گیرد. برای مسیرهای مدیریت یک کوکی جلسهٔ امضاشده را بررسی می‌کند، تلاش‌های ورود را محدود می‌کند، شمار بازدید صفحه را بدون کوکی یا آدرس IP در یک Durable Object ثبت می‌کند و برای هر نقطهٔ پایانی تجاری 403 برمی‌گرداند، مگر اینکه یک پرچم صریح سمت سرور فعال باشد. هر درخواست دیگری مستقیم به فایل‌های ایستا می‌رود.
محتوای پیش‌نویس هرگز منتشر نمی‌شود
ورودی‌های محتوا یک وضعیت دارند: پیش‌نویس، پیش‌نمایش، منتشرشده یا بایگانی. ساخت فقط برای ورودی‌های منتشرشده و پیش‌نمایش صفحه تولید می‌کند؛ صفحه‌های پیش‌نمایش noindex دارند و از فهرست‌ها و نقشهٔ سایت بیرون می‌مانند. پیش‌نویس‌ها اصلاً به فایل تبدیل نمی‌شوند؛ پس چیزی برای نشت کردن وجود ندارد.
هدرهای امنیتی از یک فایل
فایل‌های ایستا روی Workers از فایل _headers پشتیبانی می‌کنند؛ پس هدرهای امنیتی یک بار اعلام می‌شوند: یک سیاست امنیت محتوای سخت‌گیرانه که فقط مبدأ نمایشگر دمو را در قاب‌ها مجاز می‌کند، X-Content-Type-Options، یک سیاست ارجاع‌دهندهٔ محافظه‌کارانه و یک سیاست مجوزها که حسگرهایی را که سایت هرگز استفاده نمی‌کند غیرفعال می‌کند.
404 درست
پیکربندی فایل‌های ایستا برای مسیرهای ناشناخته، 404.html ساخته‌شده را با کد وضعیت واقعی 404 سرو می‌کند؛ پس موتورهای جستجو هرگز صفحه‌های soft-404 را فهرست نمی‌کنند.
بده‌بستان‌ها
- بدون شخصی‌سازی در هر درخواست. هر چیز پویایی باید در مرورگر یا Worker اجرا شود.
- برای انتشار باید دوباره ساخت. تغییر محتوا به ساخت و استقرار نیاز دارد. برای سایتی که هفته‌ای چند بار تغییر می‌کند، این یک ویژگی است: هر تغییر بازبینی و نسخه‌بندی می‌شود.
- بدون بهینه‌سازی داخلی تصویر. تصاویر صفحه هنگام ثبت به WebP تبدیل می‌شوند و در اندازه‌های ثابت سرو می‌شوند.
برای یک سایت نمایشی، این بده‌بستان‌ها به‌راحتی ارزشش را دارند: نتیجه سریع، ارزان، امن از پایه و قابل فهم است.