डिरेक्टरी साइट तयार करणे सोपे वाटते, जोपर्यंत तुम्हाला केवळ एक सुव्यवस्थित अनुक्रमणिका (table of contents) प्रदर्शित करण्यासाठी डेटाबेस, कॅशिंग लेयर्स आणि रिअॅक्टिव्ह फ्रंट-एंड फ्रेमवर्क्स जोडण्यात वेळ घालवावा लागत नाही. मी अलीकडेच सोशल मीडिया सॉफ्टवेअरची तुलना करण्यासाठी Social Tools List नावाची साइट तयार केली. माझे उद्दिष्ट ती साइट वेगाने ऑनलाइन आणणे, ती वेगवान ठेवणे आणि केवळ मी एखादे टूल जोडल्यास किंवा अपडेट केल्यास बदलणाऱ्या कंटेंटसाठी इन्फ्रास्ट्रक्चरची देखभाल टाळणे हे होते. मी 'static-first stack' निवडले: साइट जनरेशनसाठी Astro, स्ट्रक्चर्ड डेटासाठी TypeScript आणि डिप्लॉयमेंटसाठी Cloudflare Workers. परिणामी, अशी साइट तयार झाली जी त्वरित लोड होते, ज्याचा होस्टिंग खर्च नगण्य आहे आणि ज्याला कोणत्याही डेटाबेस प्रशासनाची (database administration) गरज नाही.

डिरेक्टरीसाठी 'Static-First' का योग्य आहे

अनेक वेब ॲप्स डिफॉल्टनुसार सर्व्हर रेंडरिंग किंवा सिंगल-पेज आर्किटेक्चर निवडतात कारण ते सुरक्षित आणि आधुनिक पर्याय वाटतात. परंतु प्रत्येक विनंतीवर (request) प्रत्येक साइटला डायनॅमिक युजर इनपुट मिळत नाही. Social Tools List ही 'read-heavy' रिसोर्स आहे. तुलनात्मक डेटा मी अपडेट पुश केल्यावर बदलतो, जेव्हा एखादा व्हिजिटर रिफ्रेश बटण दाबतो तेव्हा नाही. HTML आधीच रेंडर केल्यामुळे 'edge' वर डेटाबेस क्वेरी करण्याची, 'on the fly' टेम्पलेट कंपायलेशन करण्याची किंवा ब्राउझरमध्ये 'hydration overhead' ची गरज उरत नाही. मी बिल्ड टाइममध्ये साइट जनरेट करतो, स्टॅटिक फाइल्स डिप्लॉय करतो आणि एक हलका (lightweight) वर्कर रॅपर हाताळू देतो. यामुळे रिस्पॉन्स टाइम कमी राहतो आणि रनटाइम फेल्युअरचा एक मोठा प्रकार पूर्णपणे टाळता येतो.

डेटा डेटाबेसमध्ये नाही, तर TypeScript मध्ये स्टोअर करा

मी डेटाबेस वापरत नाही. डिरेक्टरीमधील प्रत्येक टूल 'slug', 'name', 'domain' आणि सपोर्टेड वर्कफ्लोच्या (workflows) ॲरेसह एका TypeScript ऑब्जेक्ट म्हणून परिभाषित केले आहे. एक सामान्य एंट्री अशी दिसते:

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

साइट तयार करण्यासाठी वापरल्या जाणाऱ्या भाषेतच डेटा स्टोअर करण्याचे दोन तात्काळ फायदे आहेत. पहिले म्हणजे, 'pull requests' हे कंटेंट रिव्ह्यू बनतात. जेव्हा मी एखादे टूल जोडतो, तेव्हा 'diff' मध्ये नेमकी फील्ड्स आणि व्हॅल्यूज दिसतात, आणि एखादा सहकारी CMS इंटरफेस न शिकताही स्पेलिंगची चूक किंवा चुकीचा डोमेन ओळखू शकतो. दुसरे म्हणजे, TypeScript कंपायलर प्रत्येक रेकॉर्डचे स्वरूप (shape) सुनिश्चित करतो. जर मी 'slug' समाविष्ट करायला विसरलो किंवा 'workflow key' मध्ये स्पेलिंगची चूक केली, तर चुकीचा डेटा पेजवर पोहोचण्यापूर्वीच बिल्ड फेल होते.

डेटाबेसमुळे मायग्रेशन्स, कनेक्शन स्ट्रिंग्स, कॅशिंग स्ट्रॅटेजीज आणि बॅकअप रूटीन्स यांसारख्या गोष्टींची गरज पडेल. मी मॅन्युअली मेंटेन करत असलेल्या काही शेकडो एन्ट्रीज असलेल्या डिरेक्टरीसाठी, हा अतिरिक्त भार (overhead) केवळ अडथळा ठरेल. TypeScript मॉड्यूल्समधील स्टॅटिक डेटा हा या मॉडेलसाठी सर्वात स्वस्त आणि योग्य पर्याय आहे. 'योग्य' या भागाला महत्त्व आहे. हे केवळ पैसे वाचवण्याबद्दल नाही; तर माझ्याकडे नसलेल्या समस्या सोडवणारे 'abstraction layers' काढून टाकण्याबद्दल आहे.

राउटिंग आणि रेंडरिंगसाठी Astro चा वापर करा

Astro एका सिंगल डायनॅमिक राउटमधून प्रत्येक टूलसाठी एक HTML पेज जनरेट करते. मी एक लेआउट कंपोनंट परिभाषित करतो आणि Astro प्रत्येक एन्ट्रीसाठी मेटाडेटा, हेडिंग्स आणि स्ट्रक्चर्ड डेटा आपोआप तयार करते. मुख्य इंडेक्स, वर्कफ्लो कॅटेगरी हब आणि वैयक्तिक डिटेल पेजेस हे सर्व एकाच डेटासेटवर आधारित असल्याने, होम पेजवरील कार्ड आणि डिटेल पेजवरील वर्णन यात तफावत असण्याची शक्यता नसते. पारंपारिक CMS सेटअपमध्ये, तुम्हाला अनेकदा तफावत (drift) दिसून येते: API एक व्हर्जन देते, कॅश दुसरे आणि क्लायंट-साइड रेंडर तिसरे. 'Single source of truth' पासून स्टॅटिक जनरेशन केल्यामुळे हे टाळता येते.

Astro चे 'island architecture' संपूर्ण पेजला JavaScript ने भरून न टाकता लहान इंटरअॅक्टिव्ह भाग जोडणे सोपे करते. साइट स्टॅटिक HTML म्हणून उपलब्ध होते आणि केवळ फिल्टरिंग स्क्रिप्ट DOM च्या विशिष्ट भागाला 'hydrate' करते. संपूर्ण डॉक्युमेंटला वेढणारे कोणतेही फ्रेमवर्क रनटाइम नसते. Astro पेज मेटाडेटाला देखील अत्यंत महत्त्वाचे मानते. प्रत्येक टूल पेजला TypeScript रेकॉर्डमधून थेट मिळणारे स्वतःचे 'title tag' आणि 'meta description' मिळते, त्यामुळे मला वेगळ्या प्लगइनची किंवा 'head management library' ची गरज पडत नाही.

फ्रेमवर्कशिवाय फिल्टरिंग

सर्च आणि फिल्टरिंगसाठी डेव्हलपर्स अनेकदा React, Vue किंवा एखादी जड 'state management library' इन्स्टॉल करतात. मी ते टाळले. Astro सर्व्हरवर संपूर्ण लिस्ट साध्या HTML स्वरूपात रेंडर करते. एक लहान व्हॅनिला JavaScript स्क्रिप्ट (एक किलोबाइटपेक्षा कमी), ब्राउझरमध्ये चालते आणि वर्कफ्लो टॅग किंवा टेक्स्ट मॅचच्या आधारे लिस्ट आयटम्सचा 'display property' बदलून फिल्टरिंग करते.

जर तुम्ही API-driven पार्श्वभूमीतून येत असाल, तर संपूर्ण markup सर्व्ह करणे अकार्यक्षम वाटू शकते. पण एका सामान्य डायनॅमिक दृष्टिकोनातील ओव्हरहेडचा विचार करा. ब्राउझर एक JavaScript bundle डाउनलोड करतो, component tree hydrate करतो, endpoint ला कॉल करतो, JSON साठी थांबतो आणि मग rows रेंडर करतो. ज्या डिरेक्टरीमध्ये शंभरपेक्षा कमी टूल्सची यादी आहे, त्यासाठी डॉक्युमेंटमध्ये आधीच असलेल्या divs लपवण्यापेक्षा ही प्रक्रिया अधिक संथ आणि कमी विश्वासार्ह आहे. माझे स्क्रिप्ट फिल्टर बटणांना event listeners जोडते, प्रत्येक row वरील data-workflow attribute वाचते आणि जे मॅच होत नाहीत त्यांना hidden सेट करते. ही क्रिया केवळ काही मिलीसेकंदात पूर्ण होते.

यादी सुरुवातीच्या HTML मध्ये असल्याने, साइट JavaScript शिवाय वापरण्यायोग्य आहे. सर्च इंजिन क्रॉलर्सना प्रत्येक लिंक आणि प्रत्येक वर्णन दिसते. संथ नेटवर्कवर असलेले किंवा स्क्रिप्ट ब्लॉकर्स वापरणारे युजर्सना देखील संपूर्ण डिरेक्टरी मिळते. फिल्टरिंग ही एक सुधारणा आहे, अडथळा नाही.

Sitemaps आणि Robots कोड म्हणून

Sitemaps आणि robots.txt हे हाताने लिहिलेले नंतरचे विचार (afterthoughts) नाहीत. ते Astro routes आहेत जे त्याच dataset आणि URL helpers चा वापर करतात जसे की