Building a directory site sounds trivial until you find yourself wiring up databases, caching layers, and reactive front

ایک ڈائریکٹری سائٹ بنانا معمولی کام لگتا ہے جب تک کہ آپ خود کو ڈیٹا بیس، کیشنگ لیئرز (caching layers)، اور ری ایکٹو فرنٹ اینڈ فریم ورکس کو جوڑتے ہوئے نہ پائیں، صرف اس لیے کہ آپ ایک ایسی چیز دکھا سکیں جو بنیادی طور پر ایک ترتیب شدہ فہرست (curated table of contents) ہے۔ میں نے حال ہی میں Social Tools List بنائی ہے، جو سوشل میڈیا سافٹ ویئر کے موازنہ کے لیے ایک سائٹ ہے۔ میرا مقصد اسے جلد از جلد آن لائن لانا، اسے تیز رکھنا، اور اس انفراسٹرکچر کو برقرار رکھنے سے بچنا تھا جو ایسے مواد کے لیے ہو جس میں تبدیلی صرف تب آتی ہے جب میں کوئی ٹول شامل کرتا ہوں یا اسے اپ ڈیٹ کرتا ہوں۔ میں نے ایک static-first stack کا انتخاب کیا: سائٹ جنریشن کے لیے Astro، اسٹرکچرڈ ڈیٹا کے لیے TypeScript، اور ڈیپلائمنٹ کے لیے Cloudflare Workers۔ اس کا نتیجہ ایک ایسی سائٹ ہے جو فوری طور پر لوڈ ہوتی ہے، اسے ہوسٹ کرنے پر تقریباً کوئی خرچہ نہیں آتا، اور اس میں ڈیٹا بیس ایڈمنسٹریشن کی ضرورت نہیں ہوتی۔

ڈائریکٹری کے لیے Static-First کیوں بہتر ہے

بہت سی ویب ایپس ڈیفالٹ کے طور پر سرور رینڈرنگ یا سنگل پیج آرکیٹیکچر کا استعمال کرتی ہیں کیونکہ یہ محفوظ اور جدید انتخاب محسوس ہوتے ہیں۔ لیکن ہر سائٹ کو ہر ریکویسٹ پر ڈائنامک یوزر ان پٹ موصول نہیں ہوتا۔ Social Tools List ایک read-heavy ریسورس ہے۔ موازنہ کا ڈیٹا تب بدلتا ہے جب میں اپ ڈیٹ پش کرتا ہوں، نہ کہ جب کوئی وزیٹر ریفریش کرتا ہے۔ پہلے سے HTML رینڈر کرنے سے edge پر ڈیٹا بیس کوئریز، آن دی فلائی ٹیمپلیٹ کمپائلیشن، یا براؤزر میں hydration overhead کی ضرورت ختم ہو جاتی ہے۔ میں بلڈ ٹائم پر سائٹ جنریٹ کرتا ہوں، اسٹیٹک فائلز ڈیپلائے کرتا ہوں، اور ایک ہلکے پھلکے worker کو ریپر (wrapper) سنبھالنے دیتا ہوں۔ اس سے رسپانس ٹائم کم رہتا ہے اور رن ٹائم کی ناکامیوں کی ایک پوری قسم کا خاتمہ ہو جاتا ہے۔

ڈیٹا کو TypeScript میں رکھیں، ڈیٹا بیس میں نہیں

میں ڈیٹا بیس استعمال نہیں کرتا۔ ڈائریکٹری میں ہر ٹول کو ایک TypeScript آبجیکٹ کے طور پر ڈیفائن کیا گیا ہے جس میں slug، نام، ڈومین، اور سپورٹڈ workflows کا ایک ایرے (array) شامل ہے۔ ایک عام انٹری کچھ اس طرح نظر آتی ہے:

{
  slug: 'buffer',
  name: 'Buffer',
  domain: 'buffer.com',
  workflows: ['scheduling', 'analytics']
}

ڈیٹا کو اسی زبان میں اسٹور کرنے کے دو فوری فوائد ہیں جس میں سائٹ بنتی ہے۔ پہلا یہ کہ، pull requests مواد کے ریویو بن جاتی ہیں۔ جب میں کوئی ٹول شامل کرتا ہوں، تو diff بالکل درست فیلڈز اور ویلیوز دکھاتا ہے، اور ایک ساتھی بغیر کسی CMS انٹرفیس کو سیکھے ٹائپو یا غلط ڈومین کو پہچان سکتا ہے۔ دوسرا یہ کہ، TypeScript کمپائلر ہر ریکارڈ کی ساخت (shape) کو یقینی بناتا ہے۔ اگر میں slug شامل کرنا بھول جاؤں یا workflow key کے ہجے غلط کر دوں، تو غلط ڈیٹا کے پیج تک پہنچنے سے پہلے ہی بلڈ فیل ہو جاتا ہے۔

ایک ڈیٹا بیس کے استعمال سے migrations، connection strings، caching strategies، اور بیک اپ روٹینز جیسے کام شامل ہو جائیں گے۔ چند سو انٹریز والی ڈائریکٹری کے لیے جسے میں خود مینیج کرتا ہوں، یہ اضافی بوجھ (overhead) محض ایک رکاوٹ ہے۔ TypeScript ماڈیولز میں اسٹیٹک ڈیٹا اس ماڈل کے لیے سب سے سستا اور درست انتخاب ہے۔ "درست" والا حصہ اہم ہے۔ یہ صرف پیسے بچانے کے بارے میں نہیں ہے؛ بلکہ یہ ان ایبسٹریکشن لیئرز (abstraction layers) کو ہٹانے کے بارے میں ہے جو ان مسائل کو حل کرتی ہیں جن کا مجھے سامنا ہی نہیں ہے۔

Routing اور Rendering کے لیے Astro کا استعمال کریں

Astro ایک ہی ڈائنامک روٹ سے ہر ٹول کے لیے ایک HTML پیج جنریٹ کرتا ہے۔ میں ایک لے آؤٹ کمپوننٹ ڈیفائن کرتا ہوں، اور Astro خود بخود ہر انٹری کے لیے میٹا ڈیٹا، ہیڈنگز، اور اسٹرکچرڈ ڈیٹا تیار کر دیتا ہے۔ چونکہ وہی ڈیٹا سیٹ مین انڈیکس، ورک فلو کیٹیگری ہبز، اور انفرادی تفصیل والے صفحات کو چلا رہا ہے، اس لیے اس بات کا کوئی امکان نہیں کہ ہوم پیج پر موجود کارڈ تفصیل والے پیج سے مختلف ڈسکرپشن دکھائے۔ روایتی CMS سیٹ اپ میں، آپ اکثر فرق (drift) دیکھتے ہیں: API ایک ورژن واپس کرتی ہے، کیش ایک اور، اور کلائنٹ سائیڈ رینڈرنگ تیسرا۔ ایک ہی "source of truth" سے اسٹیٹک جنریشن اس سے بچاتی ہے۔

Astro کا island architecture پورے پیج کو JavaScript سے بھرے بغیر چھوٹے انٹرایکٹو حصے شامل کرنا بھی آسان بناتا ہے۔ سائٹ اسٹیٹک HTML کے طور پر فراہم کی جاتی ہے، اور صرف فلٹرنگ اسکرپٹ DOM کے مخصوص حصے کو hydrate کرتا ہے۔ پورے دستاویز کو لپیٹنے والا کوئی فریم ورک رن ٹائم نہیں ہوتا۔ Astro پیج میٹا ڈیٹا کو بھی اولین اہمیت دیتا ہے۔ ہر ٹول پیج کو TypeScript ریکارڈ سے براہ راست حاصل کردہ اپنا ٹائٹل ٹیگ اور میٹا ڈسکرپشن ملتا ہے، اس لیے مجھے کسی الگ پلگ ان یا head management لائبریری کی ضرورت نہیں ہوتی۔

فریم ورک کے بغیر فلٹرنگ

سرچ اور فلٹرنگ اکثر ڈویلپرز کو React، Vue، یا کسی بھاری اسٹیٹ مینجمنٹ لائبریری کو انسٹال کرنے پر مجبور کر دیتی ہے۔ میں نے اس سے گریز کیا۔ Astro مکمل فہرست کو سرور پر سادہ HTML کے طور پر رینڈر کرتا ہے۔ ایک چھوٹا سا vanilla JavaScript اسکرپٹ، جو ایک کلو بائٹ سے بھی کم ہے، براؤزر میں چلتا ہے اور ورک فلو ٹیگ یا ٹیکسٹ میچ کی بنیاد پر لسٹ آئٹمز کی display property کو تبدیل کرتا ہے۔

اگر آپ کا پس منظر API-driven ہے تو مکمل مارک اپ فراہم کرنا غیر موثر معلوم ہو سکتا ہے۔ لیکن ایک عام ڈائنامک طریقہ کار کے اوور ہیڈ (overhead) پر غور کریں۔ براؤزر ایک JavaScript بنڈل ڈاؤن لوڈ کرتا ہے، ایک component tree کو ہائیڈریٹ (hydrate) کرتا ہے، ایک endpoint کو کال کرتا ہے، JSON کا انتظار کرتا ہے، اور پھر قطاروں (rows) کو رینڈر کرتا ہے۔ ایک ایسی ڈائریکٹری کے لیے جس میں سو سے بھی کم ٹولز کی فہرست ہو، یہ عمل ان divs کو چھپانے سے زیادہ سست اور کم قابل اعتماد ہے جو پہلے سے ہی دستاویز (document) میں موجود ہیں۔ میرا اسکرپٹ فلٹر بٹنز پر event listeners منسلک کرتا ہے، ہر قطار پر data-workflow ایٹریبیوٹ پڑھتا ہے، اور غیر مطابقت رکھنے والی چیزوں کو hidden پر سیٹ کر دیتا ہے۔ اس عمل میں صرف ملی سیکنڈز لگتے ہیں۔

چونکہ فہرست ابتدائی HTML میں موجود ہے، اس لیے سائٹ JavaScript کے بغیر بھی استعمال کے قابل ہے۔ سرچ انجن کرالرز ہر لنک اور ہر تفصیل کو دیکھ سکتے ہیں۔ سست نیٹ ورک والے یا اسکرپٹ بلاکرز استعمال کرنے والے صارفین کو بھی مکمل ڈائریکٹری دستیاب ہوتی ہے۔ فلٹرنگ ایک بہتری (enhancement) ہے، کوئی رکاوٹ (gate) نہیں۔

Sitemaps اور Robots بطور کوڈ

Sitemaps اور robots.txt کوئی ایسی چیزیں نہیں ہیں جنہیں بعد میں ہاتھ سے لکھا جائے۔ یہ Astro routes ہیں جو اسی dataset اور URL helpers کا استعمال کرتے ہیں جیسے کہ