Next.js നിങ്ങൾക്ക് നൽകുന്ന അടിസ്ഥാന സൗകര്യങ്ങൾ
- Data cache – Next.js 13+ പതിപ്പുകളിൽ ഓരോ
fetch()കോളും ഓരോ റിക്വസ്റ്റിനും അനുസൃതമായ മെമ്മറി കാഷെയിൽ (memory cache) സേവ് ചെയ്യപ്പെടുന്നു. ഒരുrevalidateഓപ്ഷൻ ചേർക്കുന്നതിലൂടെ, നിശ്ചിത ഇടവേളയ്ക്ക് ശേഷം ഡാറ്റ പുതുക്കാൻ റൺടൈമിനോട് ആവശ്യപ്പെടാം; ഇത് ആവശ്യമുള്ളപ്പോൾ മാത്രം API കോൾ നടത്തുന്ന രീതിയിലേക്ക് മാറ്റുന്നു. - Full-route cache – റെൻഡർ ചെയ്ത HTML-ഉം ഒരു റൂട്ടിന് ആവശ്യമായ ഡാറ്റയും ഫ്രെയിംവർക്ക് നിലനിർത്തുന്നു. സെർവർ വീണ്ടും റെൻഡർ ചെയ്യുന്നത് ഒഴിവാക്കുന്നതിനാൽ, സന്ദർശകർക്ക് പെട്ടെന്നുള്ള മാറ്റം (instant transition) അനുഭവപ്പെടുന്നു.
- ISR – പഴയ വേർഷൻ സേവനം നൽകിക്കൊണ്ടിരിക്കുമ്പോൾ തന്നെ സ്റ്റാറ്റിക് പേജുകൾ പശ്ചാത്തലത്തിൽ (background) പുനർനിർമ്മിക്കപ്പെടുന്നു. ഓരോ തവണയും കണ്ടന്റ് മാറുമ്പോൾ സൈറ്റ് മുഴുവനായി റീബിൽഡ് ചെയ്യാതെ തന്നെ വലിയ സൈറ്റുകൾ സ്റ്റാറ്റിക് ആയി നിലനിർത്താൻ ഇത് സഹായിക്കുന്നു.
- Server Component
cache()– ഒരു സിംഗിൾ റിക്വസ്റ്റിന്റെ സമയപരിധിക്കുള്ളിൽ, കൂടുതൽ സമയമെടുക്കുന്ന കണക്കുകൂട്ടലുകളോ (expensive calculations) ഡാറ്റാബേസ് കണക്ഷനുകളോ മെമ്മോയിസ് (memoize) ചെയ്യാൻ React-ലെcacheഹെൽപ്പർ സഹായിക്കുന്നു. ഇത് ഒരു പേജിന്റെ കമ്പോണന്റ് ട്രീക്കുള്ളിൽ ആവർത്തിച്ചുള്ള ജോലികൾ ഒഴിവാക്കുന്നു.
ഈ കാഷെകൾ "ഫസ്റ്റ്-ഹിറ്റ്" (first-hit) പ്രശ്നം പരിഹരിക്കുന്നുണ്ടെങ്കിലും അവ ഇപ്പോഴും Node പ്രോസസിനുള്ളിലാണ് പ്രവർത്തിക്കുന്നത്. സെർവറിനെയും ഡാറ്റാബേസിനെയും സംരക്ഷിക്കുന്നതിനായി, കാഷിംഗ് സംവിധാനങ്ങളെ പുറത്തേക്ക് വ്യാപിപ്പിക്കുക.
നിങ്ങൾക്ക് ചേർക്കാവുന്ന ബാഹ്യ പാളികൾ (External layers)
| പാളി (Layer) | എന്താണ് സംഭരിക്കുന്നത് | സാധാരണ ഉപയോഗിക്കുന്ന ടൂളുകൾ | എങ്ങനെ സഹായിക്കുന്നു |
|---|---|---|---|
| CDN | സ്റ്റാറ്റിക് അസറ്റുകൾ, HTML, API JSON | Cloudflare, Akamai, AWS CloudFront | ഉള്ളടക്കത്തെ എഡ്ജ് ലൊക്കേഷനുകളിലേക്ക് മാറ്റുന്നു, ഇത് ഉപയോക്താവിലേക്കുള്ള ഡാറ്റാ കൈമാറ്റം വേഗത്തിലാക്കുന്നു |
| Reverse proxy | Node-ൽ എത്തുന്നതിന് മുമ്പ് മുഴുവൻ പേജ് റെസ്പോൺസുകളും | Nginx, Varnish | കാഷെ ചെയ്ത പേജുകൾ നേരിട്ട് നൽകുന്നു, ഇത് Next.js ഇൻസ്റ്റൻസിലെ ലോഡ് കുറയ്ക്കുന്നു |
| Application-level cache | കൂടുതൽ സമയമെടുക്കുന്ന DB ക്വറികളുടെയോ API കോളുകളുടെയോ ഫലങ്ങൾ | Redis, Memcached | സെർവർ റീസ്റ്റാർട്ട് ചെയ്താലും നിലനിൽക്കുന്നതും ഒന്നിലധികം ആപ്പ് ഇൻസ്റ്റൻസുകൾക്കിടയിൽ പങ്കിടാൻ കഴിയുന്നതുമായ ഒരു വേഗതയേറിയ കീ-വാല്യൂ സ്റ്റോർ (key-value store) നൽകുന്നു |
ഓരോ പാളിയും ഒറിജിൻ ഡാറ്റാബേസിൽ നിന്ന് അകലെയാണ് ഇരിക്കുന്നത്. അതിനാൽ ഒരു പാളിയിൽ ഡാറ്റ ലഭിച്ചില്ലെങ്കിൽ (cache miss), അത് അടുത്ത പാളിയിലേക്ക് നീങ്ങുന്നു; അത്യാവശ്യ ഘട്ടത്തിൽ മാത്രമേ ഡാറ്റാബേസിലേക്ക് എത്തുന്നുള്ളൂ.
കാഷെകൾ പുതുക്കി നിലനിർത്തുക
ഇൻവാലിഡേഷൻ (Invalidation) പലപ്പോഴും ടീമുകൾക്ക് വെല്ലുവിളിയാകാറുണ്ട്. ഇതിനായി മൂന്ന് പ്രായോഗിക രീതികൾ ഉപയോഗിക്കാം:
- Time-based (TTL) – ഒരു കാഷെ എൻട്രിക്കായി നിശ്ചിത കാലാവധി (expiration) നിശ്ചയിക്കുന്നു. ഇത് കോൺഫിഗർ ചെയ്യാൻ എളുപ്പമാണ്, എന്നാൽ ടൈമർ കഴിയുന്നത് വരെ പഴയ ഡാറ്റ തന്നെ ലഭിച്ചേക്കാം.
- Event-driven – കണ്ടന്റ് മാറുമ്പോൾ വെബ്ഹൂക്ക് (webhook) അയക്കുന്ന നിങ്ങളുടെ CMS-ലോ മറ്റ് ഡാറ്റാ സ്രോതസ്സുകളിലോ ഇത് ബന്ധിപ്പിക്കാം. വെബ്ഹൂക്ക് ലഭിക്കുമ്പോൾ ബന്ധപ്പെട്ട കാഷെ എൻട്രി നീക്കം ചെയ്യപ്പെടുന്നു.
- Tag-based – ഫെച്ചുകളുടെ ഒരു ഗ്രൂപ്പിന് ഒരു ലോജിക്കൽ ടാഗ് നൽകുന്നു (ഉദാഹരണത്തിന്,
product-list). ആ ഗ്രൂപ്പിലെ ഏതെങ്കിലും ഐറ്റം മാറുമ്പോൾ,revalidateTag('product-list')എന്ന ഒറ്റ കോൾ ഉപയോഗിച്ച് ആ ടാഗുള്ള എല്ലാ എൻട്രികളും നീക്കം ചെയ്യാം.
ഈ രീതികൾ കൂട്ടിച്ചേർത്ത് ഉപയോഗിക്കുന്നതിലൂടെ ഡാറ്റയുടെ പുതുമയും (freshness) കാഷെ-ഹിറ്റ് നിരക്കും (cache-hit rates) തമ്മിൽ സന്തുലിതമായി നിലനിർത്താം.
മിക്ക ടീമുകൾക്കും അനുയോജ്യമായ ശ്രേണി (Hierarchy)
- Browser cache – സ്റ്റാറ്റിക് അസറ്റുകൾക്ക് (CSS, JS, ചിത്രങ്ങൾ) നീളമുള്ള
max-ageനൽകുന്നു, അതിനാൽ ഉപയോക്താവിന്റെ ഉപകരണം വീണ്ടും നെറ്റ്വർക്കിനോട് ഡാറ്റ ആവശ്യപ്പെടില്ല. - CDN – Next.js-ൽ നിങ്ങൾ സെറ്റ് ചെയ്യുന്ന
Cache-Controlഹെഡറുകൾ അനുസരിച്ച്, എഡ്ജ് നോഡുകൾ മുഴുവൻ HTML പേജുകളും API JSON-ഉം കാഷെ ചെയ്യുന്നു. - Reverse proxy – ഒരു Nginx അല്ലെങ്കിൽ Varnish ഇൻസ്റ്റൻസ് Next.js സെർവറിന് മുന്നിലായി പ്രവർത്തിക്കുന്നു, ഇത് അപൂർവ്വമായി മാത്രം മാറുന്ന റൂട്ടുകൾക്കായി കാഷെ ചെയ്ത റെസ്പോൺസുകൾ നൽകുന്നു.
- Next.js internal cache – ഫ്രെയിംവർക്കിന്റെ ഡാറ്റാ, റൂട്ട് കാഷെകൾ ഓരോ റിക്വസ്റ്റിനായുള്ള മെമ്മോയിസേഷനും ISR-ഉം കൈകാര്യം ചെയ്യുന്നു.
- Application cache – ക്വറി പാരാമീറ്ററുകൾ അല്ലെങ്കിൽ ടാഗുകൾ ഉപയോഗിച്ച്, കഠിനമായ ഡാറ്റാബേസ് ക്വറികളുടെ ഫലങ്ങൾ Redis സംഭരിക്കുന്നു.
- Database – ഡാറ്റയുടെ യഥാർത്ഥ ഉറവിടം; മുകളിലുള്ള എല്ലാ പാളികളിലും കാഷെ മിസ്സ് (cache miss) ഉണ്ടാകുമ്പോൾ മാത്രമേ ഇത് ഉപയോഗിക്കൂ.
ഒരു റിക്വസ്റ്റ് വരുമ്പോൾ, ഏതെങ്കിലും ഒരു പാളി മറുപടി നൽകുന്നത് വരെ അത് ഈ ലിസ്റ്റിലൂടെ താഴേക്ക് നീങ്ങുന്നു. ഏറ്റവും വേഗത്തിലുള്ള മറുപടി ലഭിക്കുന്നു, ആ റെസ്പോൺസ് ഭാവിയിലെ ആവശ്യങ്ങൾക്കായി മുകളിലെ പാളികളിലേക്ക് തിരികെ എഴുതപ്പെടുന്നു.
ഘടകങ്ങളെ ഒന്നിപ്പിക്കാം
- നിങ്ങളുടെ API റൂട്ടുകളിൽ
Cache-Controlഹെഡറുകൾ സെറ്റ് ചെയ്യുക - നിങ്ങളുടെ CDN കോൺഫിഗർ ചെയ്യുക – HTML, JSON എൻഡ് പോയിന്റുകൾക്കായി എഡ്ജ് കാഷിംഗ് പ്രവർത്തനക്ഷമമാക്കുക, കൂടാതെ CDN
Cache-Controlമാനിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക. - ഒരു റിവേഴ്സ് പ്രോക്സി വിന്യസിക്കുക – നിങ്ങളുടെ Next.js സെർവറിന് മുന്നിൽ Nginx ഉപയോഗിക്കുക.
- Redis ചേർക്കുക – കഠിനമായ ഡാറ്റാബേസ് ക്വറികളുടെ ഫലങ്ങൾ കാഷെ ചെയ്യുക.
- കമ്പോണന്റുകളിൽ
revalidateTagഉപയോഗിക്കുക – ഒരു പ്രത്യേക ടാഗിനായുള്ള Next.js ഇന്റേണൽ കാഷെ നീക്കം ചെയ്യാൻrevalidateTagവിളിക്കുക.
ചുരുക്കത്തിൽ
Next.js-നുള്ളിലെ ഒരു സിംഗിൾ കാഷെ ആദ്യത്തെ റിക്വസ്റ്റ് വേഗത്തിലാക്കുന്നു, എന്നാൽ യഥാർത്ഥ സ്കെയിലബിലിറ്റി (scalability) ലഭിക്കുന്നത് കൃത്യമായ ഒരു സ്റ്റാക്ക് വഴിയാണ്: browser → CDN → reverse proxy → framework → Redis → database. ഓരോ പാളിയും കോൺഫിഗർ ചെയ്യുക, സമയം, ഇവന്റുകൾ, ടാഗുകൾ എന്നിവ ഉപയോഗിച്ച് ഇൻവാലിഡേഷൻ കൈകാര്യം ചെയ്യുക, കൂടാതെ നിങ്ങളുടെ മെട്രിക്സുകൾ നിരീക്ഷിക്കുക. ഇത് നിങ്ങളുടെ ബാക്കെൻഡിനെ ട്രാഫിക് വർദ്ധനവിൽ നിന്ന് സംരക്ഷിക്കുകയും ലേറ്റൻസി (latency) കുറയ്ക്കുകയും ചെയ്യുന്നു.
