ഒരു ഡയറക്ടറി സൈറ്റ് നിർമ്മിക്കുന്നത് വളരെ ലളിതമായി തോന്നാം, എന്നാൽ ഡാറ്റാബേസുകൾ, കാഷിംഗ് ലെയറുകൾ, റിയാക്റ്റീവ് ഫ്രണ്ട്-എൻഡ് ഫ്രെയിംവർക്കുകൾ എന്നിവ ക്രമീകരിക്കേണ്ടി വരുമ്പോൾ അത് സങ്കീർണ്ണമായി മാറുന്നു. സോഷ്യൽ മീഡിയ സോഫ്റ്റ്വെയറുകൾ താരതമ്യം ചെയ്യുന്നതിനായി ഞാൻ അടുത്തിടെ Social Tools List എന്നൊരു സൈറ്റ് നിർമ്മിച്ചു. ഇത് വേഗത്തിൽ ഓൺലൈനിൽ എത്തിക്കുക, വേഗത നിലനിർത്തുക, കൂടാതെ ഞാൻ പുതിയ ടൂളുകൾ ചേർക്കുമ്പോഴോ അപ്ഡേറ്റ് ചെയ്യുമ്പോഴോ മാത്രം മാറ്റം വരുന്ന ഉള്ളടക്കത്തിനായി ഇൻഫ്രാസ്ട്രക്ചർ പരിപാലിക്കുന്നത് ഒഴിവാക്കുക എന്നതായിരുന്നു എന്റെ ലക്ഷ്യം. ഇതിനായി ഞാൻ ഒരു സ്റ്റാറ്റിക്-ഫസ്റ്റ് സ്റ്റാക്ക് (static-first stack) തിരഞ്ഞെടുത്തു: സൈറ്റ് ജനറേഷനായി Astro, സ്ട്രക്ചേർഡ് ഡാറ്റയ്ക്കായി TypeScript, ഡിപ്ലോയ്മെന്റിനായി Cloudflare Workers. ഇതിന്റെ ഫലമായി ഉടൻ തന്നെ ലോഡ് ആകുകയും, ഹോസ്റ്റിംഗിന് വലിയ ചിലവില്ലാത്തതും, ഡാറ്റാബേസ് അഡ്മിനിസ്ട്രേഷൻ ആവശ്യമില്ലാത്തതുമായ ഒരു സൈറ്റ് ലഭിച്ചു.
ഒരു ഡയറക്ടറിക്ക് സ്റ്റാറ്റിക്-ഫസ്റ്റ് (Static-First) സമീപനം അനുയോജ്യമാകുന്നത് എന്തുകൊണ്ട്?
പല വെബ് ആപ്പുകളും സെർവർ റെൻഡറിംഗോ സിംഗിൾ-പേജ് ആർക്കിടെക്ചറോ ആണ് ഉപയോഗിക്കുന്നത്, കാരണം അവ സുരക്ഷിതവും ആധുനികവുമായ തിരഞ്ഞെടുപ്പുകളാണെന്ന് തോന്നാം. എന്നാൽ എല്ലാ സൈറ്റുകളും ഓരോ റിക്വസ്റ്റ് വരുമ്പോഴും ഡൈനാമിക് ആയ യൂസർ ഇൻപുട്ടുകൾ സ്വീകരിക്കുന്നില്ല. Social Tools List എന്നത് കൂടുതൽ വായിക്കപ്പെടുന്ന (read-heavy) ഒരു റിസോഴ്സ് ആണ്. ഒരു സന്ദർശകൻ പേജ് റിഫ്രഷ് ചെയ്യുമ്പോഴല്ല, മറിച്ച് ഞാൻ ഒരു അപ്ഡേറ്റ് നൽകുന്ന സമയത്താണ് താരതമ്യ ഡാറ്റ മാറുന്നത്. മുൻകൂട്ടി HTML റെൻഡർ ചെയ്യുന്നത് വഴി എഡ്ജിൽ (edge) ഡാറ്റാബേസ് ക്വറികൾ നടത്തേണ്ടതില്ല, ടെംപ്ലേറ്റ് കോമ്പൈലേഷൻ ആവശ്യമില്ല, ബ്രൗസറിലെ ഹൈഡ്രേഷൻ ഓവർഹെഡ് (hydration overhead) ഒഴിവാക്കാനും സാധിക്കുന്നു. ഞാൻ സൈറ്റ് ബിൽഡ് സമയത്ത് ജനറേറ്റ് ചെയ്യുന്നു, സ്റ്റാറ്റിക് ഫയലുകൾ ഡിപ്ലോയ് ചെയ്യുന്നു, കൂടാതെ ഒരു ലൈറ്റ് വെയ്റ്റ് വർക്കർ (lightweight worker) അത് കൈകാര്യം ചെയ്യുന്നു. ഇത് റെസ്പോൺസ് സമയം കുറയ്ക്കുകയും റൺടൈം പരാജയങ്ങൾ ഒഴിവാക്കുകയും ചെയ്യുന്നു.
ഡാറ്റാബേസിന് പകരം TypeScript-ൽ ഡാറ്റ സൂക്ഷിക്കുക
ഞാൻ ഒരു ഡാറ്റാബേസ് ഉപയോഗിക്കുന്നില്ല. ഡയറക്ടറിയിലെ ഓരോ ടൂളും ഒരു slug, name, domain, കൂടാതെ സപ്പോർട്ട് ചെയ്യുന്ന workflows എന്നിവ ഉൾക്കൊള്ളുന്ന ഒരു TypeScript ഒബ്ജക്റ്റ് ആയിട്ടാണ് നിർവചിച്ചിരിക്കുന്നത്. ഒരു സാധാരണ എൻട്രി ഇപ്രകാരമാണ്:
{
slug: 'buffer',
name: 'Buffer',
domain: 'buffer.com',
workflows: ['scheduling', 'analytics']
}
സൈറ്റ് നിർമ്മിക്കാൻ ഉപയോഗിക്കുന്ന അതേ ഭാഷയിൽ തന്നെ ഡാറ്റ സൂക്ഷിക്കുന്നത് രണ്ട് പ്രധാന നേട്ടങ്ങൾ നൽകുന്നു. ഒന്നാമതായി, പുൾ റിക്വസ്റ്റുകൾ (pull requests) കണ്ടന്റ് റിവ്യൂകളായി മാറുന്നു. ഞാൻ ഒരു ടൂൾ ചേർക്കുമ്പോൾ, ഡാഫ് (diff) കൃത്യമായ ഫീൽഡുകളും വാല്യൂകളും കാണിക്കുന്നു, അതിനാൽ ഒരു CMS ഇന്റർഫേസ് പഠിക്കാതെ തന്നെ ഒരു സഹപ്രവർത്തകന് ടൈപ്പോകളോ തെറ്റായ ഡൊമൈനോ കണ്ടെത്താൻ കഴിയും. രണ്ടാമതായി, TypeScript കംപൈലർ ഓരോ റെക്കോർഡിന്റെയും ഘടന ഉറപ്പാക്കുന്നു. ഞാൻ ഒരു slug ഉൾപ്പെടുത്താൻ മറന്നാലോ അല്ലെങ്കിൽ ഒരു workflow key തെറ്റായി ടൈപ്പ് ചെയ്താലോ, തെറ്റായ ഡാറ്റ പേജിൽ എത്തുന്നതിന് മുമ്പ് തന്നെ ബിൽഡ് പരാജയപ്പെടും.
ഒരു ഡാറ്റാബേസ് ഉപയോഗിക്കുകയാണെങ്കിൽ മൈഗ്രേഷനുകൾ, കണക്ഷൻ സ്ട്രിംഗുകൾ, കാഷിംഗ് സ്ട്രാറ്റജികൾ, ബാക്കപ്പ് റൂട്ടീനുകൾ എന്നിവ ആവശ്യമായി വരും. ഞാൻ നേരിട്ട് കൈകാര്യം ചെയ്യുന്ന ഏതാനും നൂറ് എൻട്രികളുള്ള ഒരു ഡയറക്ടറിക്ക്, ഈ അധിക ജോലി ഒരു ഭാരമാണ്. ഈ മോഡലിന് ഏറ്റവും ലാഭകരവും ശരിയായതുമായ മാർഗ്ഗം TypeScript മോഡ്യൂളുകളിലെ സ്റ്റാറ്റിക് ഡാറ്റയാണ്. ഇതിൽ 'ശരിയായത്' എന്നത് പ്രധാനമാണ്. ഇത് പണം ലാഭിക്കുന്നതിനെക്കുറിച്ച് മാത്രമല്ല; എനിക്ക് ആവശ്യമില്ലാത്ത പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ ഉപയോഗിക്കുന്ന അബ്സ്ട്രാക്ഷൻ ലെയറുകൾ (abstraction layers) ഒഴിവാക്കുന്നതിനെക്കുറിച്ചാണ്.
റൂട്ടിംഗും റെൻഡറിംഗും Astro-യ്ക്ക് വിടുക
ഒരു സിംഗിൾ ഡൈനാമിക് റൂട്ടിൽ നിന്ന് ഓരോ ടൂളിനും വേണ്ടി Astro ഓരോ HTML പേജും ജനറേറ്റ് ചെയ്യുന്നു. ഞാൻ ഒരു ലേഔട്ട് കംപോണന്റ് നിർവചിക്കുന്നു, Astro ഓരോ എൻട്രിക്കും ആവശ്യമായ മെറ്റാഡാറ്റ, ഹെഡിംഗുകൾ, സ്ട്രക്ചേർഡ് ഡാറ്റ എന്നിവ സ്വയമേവ തയ്യാറാക്കുന്നു. ഒരേ ഡാറ്റാസെറ്റ് തന്നെയാണ് മെയിൻ ഇൻഡക്സ്, വർക്ക്ഫ്ലോ കാറ്റഗറി ഹബ്ബുകൾ, ഇൻഡിവിജ്വൽ ഡീറ്റെയിൽ പേജുകൾ എന്നിവയ്ക്കായി ഉപയോഗിക്കുന്നത് എന്നതിനാൽ, ഹോം പേജിലെ ഒരു കാർഡ് ഡീറ്റെയിൽ പേജിലെ വിവരണത്തിൽ നിന്നും വ്യത്യസ്തമായിരിക്കാൻ സാധ്യതയില്ല. പരമ്പരാഗത CMS സെറ്റപ്പുകളിൽ പലപ്പോഴും വ്യത്യാസങ്ങൾ കാണാറുണ്ട്: API ഒരു വേർഷനും, കാഷെ മറ്റൊരു വേർഷനും, ക്ലയന്റ് സൈഡ് റെൻഡറിംഗ് മൂന്നാമതൊരു വേർഷനും നൽകിയേക്കാം. എന്നാൽ ഒരു സിംഗിൾ സോഴ്സ് ഓഫ് ട്രൂത്ത് (single source of truth) ഉപയോഗിച്ചുള്ള സ്റ്റാറ്റിക് ജനറേഷൻ ഇത് തടയുന്നു.
പേജ് മുഴുവൻ ജാവാസ്ക്രിപ്റ്റ് ഉപയോഗിച്ച് ഭാരപ്പെടുത്താതെ തന്നെ ചെറിയ ഇന്ററാക്റ്റീവ് ഭാഗങ്ങൾ ചേർക്കാൻ Astro-യുടെ ഐലൻഡ് ആർക്കിടെക്ചർ (island architecture) സഹായിക്കുന്നു. സൈറ്റ് സ്റ്റാറ്റിക് HTML ആയിട്ടാണ് ലഭിക്കുന്നത്, ഫിൽട്ടറിംഗ് സ്ക്രിപ്റ്റ് മാത്രം അതിന്റെ ആവശ്യമായ ഭാഗങ്ങളിൽ ഹൈഡ്രേറ്റ് ചെയ്യുന്നു. മുഴുവൻ ഡോക്യുമെന്റിനെയും പൊതിഞ്ഞുനിൽക്കുന്ന ഒരു ഫ്രെയിംവർക്ക് റൺടൈം ഇതിലില്ല. പേജ് മെറ്റാഡാറ്റയെയും Astro പ്രാധാന്യത്തോടെ കാണുന്നു. ഓരോ ടൂൾ പേജിനും TypeScript റെക്കോർഡിൽ നിന്ന് നേരിട്ട് ലഭിക്കുന്ന ടൈറ്റിൽ ടാഗും മെറ്റാ ഡിസ്ക്രിപ്ഷനും ലഭിക്കുന്നു, അതിനാൽ എനിക്ക് പ്രത്യേക പ്ലഗിനുകളോ ഹെഡ് മാനേജ്മെന്റ് ലൈബ്രറികളോ ആവശ്യമില്ല.
ഫ്രെയിംവർക്ക് ഇല്ലാതെ ഫിൽട്ടറിംഗ് ചെയ്യാം
സെർച്ചിനും ഫിൽട്ടറിംഗിനും വേണ്ടി ഡെവലപ്പർമാർ പലപ്പോഴും React, Vue അല്ലെങ്കിൽ വലിയ സ്റ്റേറ്റ് മാനേജ്മെന്റ് ലൈബ്രറികൾ ഇൻസ്റ്റാൾ ചെയ്യാറുണ്ട്. ഞാൻ അത് ഒഴിവാക്കി. Astro മുഴുവൻ ലിസ്റ്റും സെർവറിൽ പ്ലെയിൻ HTML ആയി റെൻഡർ ചെയ്യുന്നു. ഒരു കിലോബൈറ്റിൽ താഴെ മാത്രം വലിപ്പമുള്ള ഒരു ചെറിയ വാനില ജാവാസ്ക്രിപ്റ്റ് (vanilla JavaScript) സ്ക്രിപ്റ്റ് ബ്രൗസറിൽ പ്രവർത്തിക്കുകയും, ഒരു വർക്ക്ഫ്ലോ ടാഗ് അല്ലെങ്കിൽ ടെക്സ്റ്റ് മാച്ച് എന്നിവയുടെ അടിസ്ഥാനത്തിൽ ലിസ്റ്റ് ഐറ്റങ്ങളുടെ ഡിസ്പ്ലേ പ്രോപ്പർട്ടി മാറ്റുകയും ചെയ്യുന്നു.
API-അധിഷ്ഠിതമായ പശ്ചാത്തലത്തിൽ നിന്ന് വരുന്ന ഒരാൾക്ക് മുഴുവൻ മാർക്കപ്പും (markup) നൽകുന്നത് കാര്യക്ഷമമല്ലാത്തതായി തോന്നാം. എന്നാൽ ഒരു സാധാരണ ഡൈനാമിക് സമീപനത്തിന്റെ അധികഭാരം പരിഗണിക്കുക. ബ്രൗസർ ഒരു JavaScript bundle ഡൗൺലോഡ് ചെയ്യുന്നു, ഒരു component tree ഹൈഡ്രേറ്റ് ചെയ്യുന്നു, ഒരു endpoint വിളിക്കുന്നു, JSON-നായി കാത്തിരിക്കുന്നു, തുടർന്ന് വരികൾ റെൻഡർ ചെയ്യുന്നു. നൂറിലധികം ടൂളുകൾ ഇല്ലാത്ത ഒരു ഡയറക്ടറിക്ക്, ഡോക്യുമെന്റിൽ നിലവിലുള്ള div-കൾ മറച്ചുവെക്കുന്നതിനേക്കാൾ സാവധാനത്തിലും കുറഞ്ഞ വിശ്വാസ്യതയുള്ളതുമാണ് ഈ പ്രക്രിയ. എന്റെ സ്ക്രിപ്റ്റ് ഫിൽട്ടർ ബട്ടണുകളിൽ event listeners ഘടിപ്പിക്കുന്നു, ഓരോ വരിയിലെയും data-workflow attribute വായിക്കുന്നു, ഒത്തുപോകാത്തവയെ hidden ആയി മാറ്റുന്നു. ഈ പ്രക്രിയ നടക്കാൻ ഏതാനും മില്ലിസെക്കൻഡുകൾ മാത്രമേ എടുക്കുന്നുള്ളൂ.
ലിസ്റ്റ് ആദ്യത്തെ HTML-ൽ തന്നെ ഉള്ളതുകൊണ്ട്, JavaScript ഇല്ലാതെയും സൈറ്റ് ഉപയോഗിക്കാൻ സാധിക്കും. സെർച്ച് എഞ്ചിൻ ക്രോളറുകൾക്ക് എല്ലാ ലിങ്കുകളും വിവരണങ്ങളും കാണാൻ കഴിയും. പതുക്കെയുള്ള നെറ്റ്വർക്കിലുള്ളവർക്കോ സ്ക്രിപ്റ്റ് ബ്ലോക്കറുകൾ ഉപയോഗിക്കുന്നവർക്കോ പോലും പൂർണ്ണമായ ഡയറക്ടറി ലഭ്യമാകും. ഫിൽട്ടറിംഗ് എന്നത് ഒരു മെച്ചപ്പെടുത്തൽ മാത്രമാണ്, അല്ലാതെ ഒരു തടസ്സമല്ല.
സൈറ്റ്മാപ്പുകളും റോബോട്ടുകളും കോഡ് ആയി
Sitemaps-ഉം robots.txt-ഉം കൈകൊണ്ട് എഴുതുന്ന പിൽക്കാല ചിന്തകളല്ല. അവ ഒരേ ഡാറ്റാസെറ്റും URL helpers-ഉം ഉപയോഗിക്കുന്ന Astro റൂട്ടുകളാണ്