ఒక డైరెక్టరీ సైట్ను నిర్మించడం చాలా సులభం అనిపిస్తుంది, కానీ కేవలం ఒక క్యూరేటెడ్ టేబుల్ ఆఫ్ కంటెంట్స్ను ప్రదర్శించడానికి మాత్రమే డేటాబేస్లు, క్యాషింగ్ లేయర్లు మరియు రియాక్టివ్ ఫ్రంట్-ఎండ్ ఫ్రేమ్వర్క్లను అనుసంధానించాల్సి వచ్చినప్పుడు అది అంత సులభం కాదు. నేను ఇటీవల సోషల్ మీడియా సాఫ్ట్వేర్లను పోల్చడానికి 'Social Tools List' అనే సైట్ను రూపొందించాను. దీనిని త్వరగా ఆన్లైన్లోకి తీసుకురావడం, వేగంగా ఉండేలా చూడటం మరియు నేను ఒక టూల్ను జోడించినప్పుడు లేదా అప్డేట్ చేసినప్పుడు మాత్రమే మారే కంటెంట్ కోసం ఇన్ఫ్రాస్ట్రక్చర్ను నిర్వహించకుండా ఉండటమే నా లక్ష్యం. నేను ఒక static-first stackను ఎంచుకున్నాను: సైట్ జనరేషన్ కోసం Astro, స్ట్రక్చర్డ్ డేటా కోసం TypeScript, మరియు డిప్లాయ్మెంట్ కోసం Cloudflare Workers. దీని ఫలితంగా తక్షణమే లోడ్ అయ్యే, హోస్టింగ్ కోసం దాదాపు ఏ ఖర్చు లేని మరియు డేటాబేస్ అడ్మినిస్ట్రేషన్ అవసరం లేని సైట్ సిద్ధమైంది.
డైరెక్టరీ కోసం Static-First ఎందుకు సరైనది?
చాలా వెబ్ యాప్లు సర్వర్ రెండరింగ్ లేదా single-page architecturesను డిఫాల్ట్గా ఎంచుకుంటాయి, ఎందుకంటే అవి సురక్షితమైన మరియు ఆధునిక ఎంపికలుగా అనిపిస్తాయి. కానీ ప్రతి రిక్వెస్ట్పై ప్రతి సైట్ డైనమిక్ యూజర్ ఇన్పుట్ను స్వీకరించదు. Social Tools List అనేది ఒక read-heavy resource. పోలిక డేటా నేను అప్డేట్ను పుష్ చేసినప్పుడు మారుతుంది, సందర్శకుడు పేజీని రిఫ్రెష్ చేసినప్పుడు కాదు. HTMLని ముందే రెండర్ చేయడం వల్ల edge వద్ద డేటాబేస్ క్వెరీల అవసరం, on the fly టెంప్లేట్ కంపైలేషన్ లేదా బ్రౌజర్లో hydration overhead వంటివి తగ్గుతాయి. నేను సైట్ను build timeలో జనరేట్ చేస్తాను, స్టాటిక్ ఫైల్లను డిప్లాయ్ చేస్తాను మరియు ఒక లైట్వెయిట్ వర్కర్ (worker) ద్వారా దానిని నిర్వహిస్తాను. ఇది రెస్పాన్స్ టైమ్ను తక్కువగా ఉంచుతుంది మరియు రన్టైమ్ ఫెయిల్యూర్స్ను పూర్తిగా నివారిస్తుంది.
డేటాను డేటాబేస్లో కాకుండా TypeScriptలో నిల్వ చేయండి
నేను డేటాబేస్ను ఉపయోగించను. డైరెక్టరీలోని ప్రతి టూల్ ఒక slug, name, domain మరియు సపోర్ట్ చేసే workflows యొక్క array కలిగిన TypeScript ఆబ్జెక్ట్గా నిర్వచించబడింది. ఒక సాధారణ ఎంట్రీ ఇలా ఉంటుంది:
{
slug: 'buffer',
name: 'Buffer',
domain: 'buffer.com',
workflows: ['scheduling', 'analytics']
}
సైట్ను నిర్మించే భాషలోనే డేటాను నిల్వ చేయడం వల్ల రెండు తక్షణ ప్రయోజనాలు ఉన్నాయి. మొదటిది, pull requests కంటెంట్ రివ్యూలుగా మారుతాయి. నేను ఒక టూల్ను జోడించినప్పుడు, diff ఖచ్చితమైన ఫీల్డ్లు మరియు విలువలను చూపుతుంది, తద్వారా నా టీమ్ సభ్యుడు CMS ఇంటర్ఫేస్ను నేర్చుకోకుండానే ఒక typo లేదా తప్పు డొమైన్ను గుర్తించగలరు. రెండవది, TypeScript కంపైలర్ ప్రతి రికార్డ్ యొక్క రూపాన్ని (shape) ఖచ్చితంగా ఉండేలా చూస్తుంది. నేను slug చేర్చడం మర్చిపోయినా లేదా workflow కీని తప్పుగా రాసినా, తప్పుడు డేటా పేజీకి చేరుకోకముందే build ఫెయిల్ అవుతుంది.
డేటాబేస్ వాడితే migrations, connection strings, caching strategies మరియు backup routines అవసరమవుతాయి. నేను మాన్యువల్గా నిర్వహించే కొన్ని వందల ఎంట్రీలు ఉన్న డైరెక్టరీకి, ఆ ఓవర్హెడ్ అనవసరమైన భారం. ఈ మోడల్ కోసం TypeScript మాడ్యూల్స్లో స్టాటిక్ డేటాను ఉపయోగించడం అనేది అత్యంత తక్కువ ఖర్చుతో కూడిన సరైన ఎంపిక. ఇక్కడ 'సరైన' అనే పదం ముఖ్యం. ఇది కేవలం డబ్బు ఆదా చేయడం గురించి మాత్రమే కాదు; నాకు లేని సమస్యలను పరిష్కరించే abstraction layersలను తొలగించడం గురించి కూడా.
రూటింగ్ మరియు రెండరింగ్ను Astroకే వదిలేయండి
Astro ఒకే డైనమిక్ రూట్ నుండి ప్రతి టూల్ కోసం ఒక HTML పేజీని జనరేట్ చేస్తుంది. నేను ఒక layout componentను నిర్వచిస్తే, Astro ప్రతి ఎంట్రీ కోసం metadata, హెడ్డింగ్లు మరియు స్ట్రక్చర్డ్ డేటాను ఆటోమేటిక్గా రూపొందిస్తుంది. ఒకే dataset మెయిన్ ఇండెక్స్, workflow category hubs మరియు వ్యక్తిగత వివరాల పేజీలను నడిపించడం వల్ల, హోమ్ పేజీలోని కార్డ్ మరియు వివరాల పేజీలోని వివరణ వేరువేరుగా ఉండే అవకాశం లేదు. సాంప్రదాయ CMS సెటప్లలో, తరచుగా డేటాలో తేడాలు (drift) కనిపిస్తాయి: API ఒక వెర్షన్ను, cache మరొక వెర్షన్ను మరియు client-side render మూడవ వెర్షన్ను చూపుతాయి. Single source of truth నుండి స్టాటిక్ జనరేషన్ చేయడం వల్ల ఆ సమస్యను నివారించవచ్చు.
Astro యొక్క island architecture, మొత్తం పేజీని JavaScriptతో నింపకుండానే చిన్న ఇంటరాక్టివ్ భాగాలను జోడించడం సులభతరం చేస్తుంది. సైట్ స్టాటిక్ HTML రూపంలో ఉంటుంది మరియు కేవలం ఫిల్టరింగ్ స్క్రిప్ట్ మాత్రమే DOM యొక్క నిర్దిష్ట భాగాన్ని hydrate చేస్తుంది. మొత్తం డాక్యుమెంట్ను చుట్టేసే framework runtime ఇక్కడ ఉండదు. Astro పేజీ metadataను కూడా ప్రాధాన్యత కలిగిన అంశంగా పరిగణిస్తుంది. ప్రతి టూల్ పేజీకి TypeScript రికార్డ్ నుండి నేరుగా తీసుకోబడిన దాని స్వంత title tag మరియు meta description లభిస్తాయి, కాబట్టి నాకు ప్రత్యేక ప్లగిన్ లేదా head management library అవసరం లేదు.
ఫ్రేమ్వర్క్ లేకుండా ఫిల్టరింగ్
సెర్చ్ మరియు ఫిల్టరింగ్ కోసం డెవలపర్లు తరచుగా React, Vue లేదా భారీ state management libraryలను ఇన్స్టాల్ చేస్తారు. నేను దానిని నివారించాను. Astro పూర్తి జాబితాను సర్వర్లో ప్లెయిన్ HTMLగా రెండర్ చేస్తుంది. ఒక కిలోబైట్ కంటే తక్కువ పరిమాణం ఉన్న చిన్న vanilla JavaScript స్క్రిప్ట్ బ్రౌజర్లో రన్ అవుతుంది మరియు workflow tag లేదా టెక్స్ట్ మ్యాచ్ ఆధారంగా list items యొక్క display propertyని మారుస్తుంది.
మీరు API-ఆధారిత నేపథ్యం నుండి వస్తే, పూర్తి మార్కప్ను అందించడం అసమర్థంగా అనిపించవచ్చు. కానీ ఒక సాధారణ డైనమిక్ విధానం వల్ల కలిగే ఓవర్హెడ్ను పరిగణనలోకి తీసుకోండి. బ్రౌజర్ ఒక JavaScript బండిల్ను డౌన్లోడ్ చేస్తుంది, ఒక కాంపోనెంట్ ట్రీని హైడ్రేట్ చేస్తుంది, ఒక ఎండ్పాయింట్ను పిలుస్తుంది, JSON కోసం వేచి ఉంటుంది మరియు ఆపై రోలను రెండర్ చేస్తుంది. వంద కంటే తక్కువ టూల్స్ను జాబితా చేసే డైరెక్టరీ కోసం, డాక్యుమెంట్లో ఇప్పటికే ఉన్న divలను దాచడం కంటే ఆ ప్రక్రియ నెమ్మదిగా మరియు తక్కువ నమ్మదగినదిగా ఉంటుంది. నా స్క్రిప్ట్ ఫిల్టర్ బటన్లకు ఈవెంట్ లిజనర్లను జోడిస్తుంది, ప్రతి రోలోని data-workflow ఆట్రిబ్యూట్ను చదువుతుంది మరియు సరిపోని వాటిని hidden గా మారుస్తుంది. ఈ ప్రక్రియ కేవలం మిల్లీసెకన్లలోనే పూర్తవుతుంది.
జాబితా ప్రారంభ HTMLలోనే ఉండటం వల్ల, JavaScript లేకుండానే సైట్ను ఉపయోగించవచ్చు. సెర్చ్ ఇంజిన్ క్రాలర్లు ప్రతి లింక్ను మరియు ప్రతి వివరణను చూడగలరు. నెమ్మదైన నెట్వర్క్లో ఉన్న వినియోగదారులు లేదా స్క్రిప్ట్ బ్లాకర్లను ఉపయోగించే వారు కూడా పూర్తి డైరెక్టరీని పొందగలరు. ఫిల్టరింగ్ అనేది ఒక అదనపు సౌకర్యం మాత్రమే, అది ఒక అడ్డంకి కాదు.
కోడ్గా సైట్మ్యాప్స్ మరియు రోబోట్స్ (Sitemaps and Robots as Code)
Sitemaps మరియు robots.txt అనేవి చేత్తో రాసే అదనపు అంశాలు కావు. ఇవి అదే డేటాసెట్ మరియు URL హెల్పర్లను ఉపయోగించే Astro రూట్ల లాగా...