ஒரு டைரக்டரி தளத்தை உருவாக்குவது எளிது என்று தோன்றலாம், ஆனால் ஒரு தொகுக்கப்பட்ட உள்ளடக்க அட்டவணையை (curated table of contents) காண்பிப்பதற்காகவே தரவுத்தளங்கள் (databases), கேச்சிங் லேயர்கள் (caching layers) மற்றும் ரியாக்டிவ் பிரண்ட்-எண்ட் பிரேம்வொர்க்குகளை (reactive front-end frameworks) இணைக்க வேண்டிய சூழலில் நீங்கள் சிக்கிக்கொள்ளலாம். சமூக ஊடக மென்பொருட்களை ஒப்பிடுவதற்கான ஒரு தளமான Social Tools List-ஐ நான் சமீபத்தில் உருவாக்கினேன். அதை விரைவாக இணையத்தில் கொண்டு வருவதும், வேகமானதாக வைத்திருப்பதும், நான் ஒரு கருவியைச் சேர்க்கும் அல்லது புதுப்பிக்கும் போது மட்டுமே மாறும் உள்ளடக்கத்திற்காக உள்கட்டமைப்பைப் பராமரிப்பதைத் தவிர்ப்பதும் எனது இலக்காக இருந்தது. நான் ஒரு static-first stack-ஐத் தேர்ந்தெடுத்தேன்: தள உருவாக்கத்திற்கு Astro, கட்டமைக்கப்பட்ட தரவுகளுக்கு (structured data) TypeScript மற்றும் வரிசைப்படுத்துதலுக்கு (deployment) Cloudflare Workers. இதன் விளைவாக, உடனடியாகத் தொடங்கும், ஹோஸ்டிங் செய்ய மிகக் குறைந்த செலவே ஆகும் மற்றும் தரவுத்தள நிர்வாகம் (database administration) தேவையில்லாத ஒரு தளம் கிடைக்கிறது.
ஒரு டைரக்டரிக்கு ஏன் Static-First முறை சிறந்தது?
பல இணைய செயலிகள் சர்வர் ரெண்டரிங் (server rendering) அல்லது சிங்கிள்-பேஜ் ஆர்க்கிடெக்சர்களை (single-page architectures) இயல்பாகப் பயன்படுத்துகின்றன, ஏனெனில் அவை பாதுகாப்பான மற்றும் நவீனத் தேர்வாகத் தோன்றுகின்றன. ஆனால் எல்லாத் தளங்களும் ஒவ்வொரு கோரிக்கையின் போதும் (request) மாறும் பயனர் உள்ளீடுகளைப் பெறுவதில்லை. Social Tools List என்பது அதிகப்படியான வாசிப்புத் தேவை கொண்ட (read-heavy) ஒரு ஆதாரமாகும். ஒப்பீட்டுத் தரவுகள் நான் ஒரு அப்டேட்டைப் பதிவேற்றும்போது மட்டுமே மாறும், ஒரு பார்வையாளர் பக்கத்தைப் புதுப்பிக்கும்போது (refresh) அல்ல. முன்கூட்டியே HTML-ஐ ரெண்டர் செய்வது, எட்ஜ் (edge) நிலையில் தரவுத்தள வினவல்களின் (database queries) தேவையையோ, நிகழ்நேர டெம்ப்ளேட் கம்பைலேஷன் (template compilation) தேவையையோ அல்லது பிரவுசரில் ஹைட்ரேஷன் (hydration) சுமையையோ நீக்குகிறது. நான் தளத்தை பில்ட் நேரத்திலேயே (build time) உருவாக்கி, ஸ்டேடிக் கோப்புகளை வரிசைப்படுத்தி, ஒரு லேசான வொர்க்கரை (lightweight worker) அதன் மேலாண்மைக்காகப் பயன்படுத்துகிறேன். இது பதிலளிக்கும் நேரத்தைக் (response times) குறைப்பதோடு, ரன்டைம் தோல்விகளைத் தவிர்க்கிறது.
தரவை தரவுத்தளத்தில் அல்ல, TypeScript-இல் சேமிக்கவும்
நான் தரவுத்தளத்தைப் பயன்படுத்துவதில்லை. டைரக்டரியில் உள்ள ஒவ்வொரு கருவியும் slug, பெயர், டொமைன் மற்றும் ஆதரிக்கப்படும் பணிப்பாய்வுகளின் (workflows) வரிசை ஆகியவற்றைக் கொண்ட ஒரு TypeScript ஆப்ஜெக்ட்டாக வரையறுக்கப்பட்டுள்ளது. ஒரு பொதுவான பதிவு இவ்வாறு இருக்கும்:
{
slug: 'buffer',
name: 'Buffer',
domain: 'buffer.com',
workflows: ['scheduling', 'analytics']
}
தளத்தை உருவாக்கும் அதே மொழியில் தரவைச் சேமிப்பதன் மூலம் இரண்டு உடனடி நன்மைகள் கிடைக்கின்றன. முதலாவதாக, புல் ரிக்வெஸ்ட்கள் (pull requests) உள்ளடக்க ஆய்வுகளாக (content reviews) மாறுகின்றன. நான் ஒரு கருவியைச் சேர்க்கும்போது, 'diff' துல்லியமான புலங்களையும் (fields) மதிப்புகளையும் காட்டும், மேலும் ஒரு குழு உறுப்பினர் CMS இடைமுகத்தைக் கற்காமலேயே ஒரு தட்டச்சுப் பிழையையோ அல்லது தவறான டொமைனையோ கண்டறிய முடியும். இரண்டாவதாக, TypeScript கம்பைலர் ஒவ்வொரு பதிவின் வடிவத்தையும் (shape) உறுதி செய்கிறது. நான் ஒரு slug-ஐச் சேர்க்க மறந்தாலோ அல்லது ஒரு workflow கீயைத் தவறாகத் தட்டச்சு செய்தாலோ, தவறான தரவு ஒரு பக்கத்தை அடைவதற்கு முன்பே பில்ட் தோல்வியடையும்.
ஒரு தரவுத்தளம் மைக்ரேஷன்கள் (migrations), கனெக்ஷன் ஸ்ட்ரிங்ஸ் (connection strings), கேச்சிங் உத்திகள் (caching strategies) மற்றும் பேக்கப் நடைமுறைகளை (backup routines) அறிமுகப்படுத்தும். நான் கைமுறையாகப் பராமரிக்கும் சில நூறு பதிவுகளைக் கொண்ட ஒரு டைரக்டரிக்கு, அந்த கூடுதல் சுமை ஒரு தேவையற்றத் தடையாகும். இந்த மாதிரிக்கான மிகக் குறைந்த செலவிலான சரியானத் தேர்வு TypeScript மாடியூல்களில் உள்ள ஸ்டேடிக் தரவுதான். அந்த "சரியான" என்ற பகுதி முக்கியமானது. இது பணத்தைச் சேமிப்பது பற்றியது மட்டுமல்ல; எனக்குத் தேவையில்லாத சிக்கல்களுக்குத் தீர்வுகாணும் அப்ஸ்ட்ராக்ஷன் லேயர்களை (abstraction layers) நீக்குவதைப் பற்றியதுமாகும்.
ரூட்டிங் மற்றும் ரெண்டரிங்கை Astro-விடம் ஒப்படைக்கவும்
Astro ஒரு ஒற்றை டைனமிக் ரூட்டிலிருந்து (dynamic route) ஒவ்வொரு கருவிக்கும் ஒரு HTML பக்கத்தை உருவாக்குகிறது. நான் ஒரு லேஅவுட் காம்பொனென்ட்டை (layout component) வரையறுக்கிறேன், மேலும் Astro ஒவ்வொரு பதிவிற்கும் மெட்டாடேட்டா (metadata), தலைப்புகள் மற்றும் கட்டமைக்கப்பட்ட தரவை தானாகவே உருவாக்குகிறது. ஒரே தரவுத்தொகுப்பு (dataset) முக்கிய இன்டெக்ஸ், பணிப்பாய்வு வகை மையங்கள் (workflow category hubs) மற்றும் தனிப்பட்ட விவரப் பக்கங்களை இயக்குவதால், முகப்புப் பக்கத்தில் உள்ள ஒரு கார்டு, விவரப் பக்கத்தில் உள்ள விளக்கத்திலிருந்து மாறுபடும் வாய்ப்பு இல்லை. பாரம்பரிய CMS அமைப்புகளில், நீங்கள் பெரும்பாலும் ஒரு முரண்பாட்டைக் காண்பீர்கள்: API ஒரு பதிப்பையும், கேச் (cache) வேறொரு பதிப்பையும், கிளையண்ட்-சைடு ரெண்டரிங் மூன்றாவது பதிப்பையும் வழங்கும். ஒற்றை ஆதாரத்திலிருந்து (single source of truth) ஸ்டேடிக் ஜெனரேஷன் செய்வதன் மூலம் இதைத் தடுக்க முடியும்.
Astro-வின் ஐலண்ட் ஆர்க்கிடெக்சர் (island architecture), முழுப் பக்கத்தையும் JavaScript மூலம் பாரமாக்காமல் சிறிய ஊடாடும் பகுதிகளை (interactive pieces) எளிதாகச் சேர்க்க உதவுகிறது. தளம் ஸ்டேடிக் HTML ஆக வழங்கப்படுகிறது, மேலும் ஃபில்டரிங் ஸ்கிரிப்ட் மட்டும் DOM-ன் குறிப்பிட்ட பகுதியை ஹைட்ரேட் (hydrate) செய்கிறது. முழு ஆவணத்தையும் சுற்றியுள்ள பிரேம்வொர்க் ரன்டைம் (framework runtime) எதுவும் இல்லை. Astro பக்க மெட்டாடேட்டாவையும் ஒரு முக்கிய விஷயமாகக் கருதுகிறது. ஒவ்வொரு கருவிப் பக்கமும் TypeScript பதிவிலிருந்து நேரடியாகப் பெறப்பட்ட தனிப்பட்ட title tag மற்றும் meta description ஆகியவற்றைப் பெறுகிறது, எனவே எனக்குத் தனிப் பிளகின் அல்லது head management library தேவையில்லை.
பிரேம்வொர்க் இல்லாமலேயே ஃபில்டரிங் செய்தல்
தேடல் மற்றும் ஃபில்டரிங் செய்யும்போது டெவலப்பர்கள் பெரும்பாலும் React, Vue அல்லது ஒரு கனமான state management library-ஐ நிறுவத் தூண்டப்படுவார்கள். நான் அதைத் தவிர்த்தேன். Astro முழுப் பட்டியலையும் சர்வரில் சாதாரண HTML ஆக ரெண்டர் செய்கிறது. ஒரு கிலோபைட்டிற்கும் குறைவான சிறிய vanilla JavaScript ஸ்கிரிப்ட் பிரவுசரில் இயங்கி, ஒரு workflow டேக் அல்லது உரை ஒற்றுமையின் (text match) அடிப்படையில் பட்டியல் உருப்படிகளின் (list items) display property-ஐ மாற்றுகிறது.
நீங்கள் API-அடிப்படையிலான பின்னணியிலிருந்து வந்தவர் என்றால், முழுமையான markup-ஐ வழங்குவது திறமையற்றதாகத் தோன்றலாம். ஆனால் ஒரு வழக்கமான டைனமிக் அணுகுமுறையின் சுமையை (overhead) கருத்தில் கொள்ளுங்கள். பிரவுசர் ஒரு JavaScript bundle-ஐப் பதிவிறக்கம் செய்கிறது, ஒரு component tree-ஐ ஹைட்ரேட் (hydrate) செய்கிறது, ஒரு endpoint-ஐ அழைக்கிறது, JSON-க்காகக் காத்திருக்கிறது, பின்னர் வரிசைகளை (rows) ரெண்டர் செய்கிறது. நூறுக்கும் குறைவான கருவிகளைப் பட்டியலிடும் ஒரு டைரக்டரிக்கு, ஆவணத்திலேயே ஏற்கனவே இருக்கும் divs-களை மறைப்பதை விட, இந்தச் செயல்முறை மெதுவானது மற்றும் நம்பகத்தன்மை குறைந்தது. எனது ஸ்கிரிப்ட் ஃபில்டர் பட்டன்களுக்கு event listeners-களை இணைக்கிறது, ஒவ்வொரு வரிசையிலும் உள்ள data-workflow attribute-ஐப் படிக்கிறது, மேலும் பொருந்தாதவற்றை (non-matches) மறைக்கப்பட்டதாக (hidden) மாற்றுகிறது. இந்தச் செயல்பாடு மில்லி விநாடிகளில் முடிந்துவிடுகிறது.
பட்டியல் ஆரம்பக்கட்ட HTML-லேயே இருப்பதால், JavaScript இல்லாமலேயே இணையதளத்தைப் பயன்படுத்த முடியும். தேடுபொறி க்ராலர்கள் (Search engine crawlers) ஒவ்வொரு லிங்க் மற்றும் ஒவ்வொரு விளக்கத்தையும் பார்க்க முடியும். மெதுவான நெட்வொர்க்கில் உள்ள பயனர்கள் அல்லது ஸ்கிரிப்ட் பிளாக்கர்களைப் (script blockers) பயன்படுத்தும் பயனர்களும் முழுமையான டைரக்டரியைப் பெற முடியும். ஃபில்டரிங் என்பது ஒரு கூடுதல் வசதியே தவிர, அது ஒரு தடையல்ல.
Sitemaps மற்றும் Robots-ஐ குறியீடாகக் கையாளுதல்
Sitemaps மற்றும் robots.txt ஆகியவை பின்னர் யோசிக்கப்பட்டு கையால் எழுதப்படுபவை அல்ல. அவை அதே dataset மற்றும் URL helpers-களைப் பயன்படுத்தும் Astro routes ஆகும்.