Gryffin Forge
Next.jsCloudflareکارکردگی

Cloudflare Workers پر اسٹیٹک Next.js سائٹ شائع کرنا

یہ سائٹ ایک چھوٹے Worker سے پیش ہونے والا مکمل اسٹیٹک Next.js ایکسپورٹ کیوں ہے: تیز صفحات، تقریباً صفر لاگت، سرور سائیڈ ایڈمن تحفظ اور سیکیورٹی ہیڈرز۔

3 منٹ کا مطالعہGryffin Forge

یہ ویب سائٹ Next.js اور React سے بنی ہے، مگر کہیں کوئی Node.js سرور نہیں چلتا۔ ہر عوامی صفحہ بلڈ کے وقت اسٹیٹک HTML میں پہلے سے بنتا ہے اور Cloudflare کے ایج سے پیش ہوتا ہے۔ ایک چھوٹا Worker وہ چند کام کرتا ہے جنہیں واقعی سرور چاہیے۔ وجہ اور ٹکڑوں کا جوڑ یہ ہے۔

پہلے اسٹیٹک

پورٹ فولیو اور ڈیمو سائٹ پر تقریباً سب کچھ مستقل مواد ہے: ڈیمو تفصیلات، مضامین، کیس اسٹڈیز، ٹول صفحات۔ کچھ بھی ہر وزیٹر کے لیے نہیں بدلتا، اس لیے ہر درخواست پر بنانا بغیر فائدے کے تاخیر اور لاگت بڑھاتا ہے۔

output: "export" کے ساتھ Next.js ہر راستہ — بشمول /demos/[slug] جیسے متحرک راستے جو generateStaticParams سے گنے جاتے ہیں — سادہ HTML فائلوں میں بناتا ہے۔ نتیجہ:

  • تیز پہلا ڈسپلے — HTML مکمل پہنچتا ہے، سرور رینڈرنگ وقت کے بغیر۔
  • کم سے کم JavaScript — سرور اجزا کوئی کلائنٹ کوڈ نہیں بھیجتے؛ صرف تعاملی حصے (فلٹرز، کیلکولیٹرز، ڈیمو ویور) فعال ہوتے ہیں۔
  • تقریباً صفر چلانے کی لاگت — Cloudflare پر اسٹیٹک فائلیں کیش سے پیش ہوتی ہیں۔
  • ناکامی کی سادہ صورتیں — کوئی ایپلیکیشن سرور نہیں جو کریش ہو۔

جہاں سرور اب بھی چاہیے

تین چیزیں اسٹیٹک نہیں ہو سکتیں:

  1. ایڈمن حصہ کسی بھی مواد بھیجنے سے پہلے محفوظ ہونا چاہیے۔
  2. اعداد و شمار اور خرابی کی رپورٹس کو وصول کرنے کا اینڈ پوائنٹ چاہیے۔
  3. تجارتی صلاحیتیں سرور سائیڈ پر رد ہونی چاہییں، صرف چھپائی نہیں۔

ایک Worker صرف /admin اور /api/* کے لیے اسٹیٹک فائلوں کے آگے ہے۔ یہ ایڈمن راستوں کے لیے دستخط شدہ سیشن کوکی جانچتا، لاگ ان کوششیں محدود کرتا، کوکیز یا IP پتوں کے بغیر Durable Object میں صفحہ دیکھنے کی گنتی رکھتا، اور کسی بھی تجارتی اینڈ پوائنٹ پر 403 لوٹاتا ہے جب تک واضح سرور سائیڈ جھنڈا نہ لگا ہو۔ باقی ہر درخواست سیدھی اسٹیٹک فائلوں پر جاتی ہے۔

ڈرافٹ مواد کبھی شائع نہیں ہوتا

مواد کی ہر چیز کی ایک حالت ہے: ڈرافٹ، پیش نظارہ، شائع شدہ یا محفوظ شدہ۔ بلڈ صرف شائع شدہ اور پیش نظارہ کے صفحات بناتا ہے؛ پیش نظارہ صفحات پر noindex ہوتا ہے اور وہ فہرستوں اور سائٹ میپ سے باہر رہتے ہیں۔ ڈرافٹ کبھی فائل ہی نہیں بنتے، اس لیے لیک ہونے کو کچھ نہیں۔

فائل سے سیکیورٹی ہیڈرز

Workers پر اسٹیٹک فائلیں _headers فائل کی حمایت کرتی ہیں، اس لیے سیکیورٹی ہیڈرز ایک بار لکھے جاتے ہیں: سخت مواد سیکیورٹی پالیسی جو فریمز میں صرف ڈیمو رینڈرر کی اجازت دیتی ہے، X-Content-Type-Options، محتاط ریفرر پالیسی اور اجازتوں کی پالیسی جو وہ سینسر بند کرتی ہے جو سائٹ کبھی استعمال نہیں کرتی۔

درست 404

اسٹیٹک فائل کنفیگریشن نامعلوم راستوں پر بنی ہوئی 404.html کو اصل 404 اسٹیٹس کوڈ کے ساتھ پیش کرتی ہے، اس لیے سرچ انجن کبھی soft-404 صفحات انڈیکس نہیں کرتے۔

سودے

  • ہر درخواست پر ذاتی بنانا نہیں۔ ہر متحرک چیز براؤزر یا Worker میں چلنی چاہیے۔
  • شائع کرنے کے لیے دوبارہ بلڈ۔ مواد کی تبدیلی بلڈ اور ڈیپلائے مانگتی ہے۔ ہفتے میں چند بار بدلنے والی سائٹ کے لیے یہ خوبی ہے: ہر تبدیلی جانچی اور ورژن ہوتی ہے۔
  • تصویر کی خودکار بہتری نہیں۔ اسکرین شاٹس لیتے وقت WebP میں بدلے اور مقررہ سائز میں پیش ہوتے ہیں۔

شوکیس سائٹ کے لیے یہ سودے آسانی سے فائدہ مند ہیں: نتیجہ تیز، سستا، بنیادی طور پر محفوظ اور سمجھنے میں آسان ہے۔