Next.js உங்களுக்குத் தானாகவே (out of the box) வழங்கும் வசதிகள்

  • Data cache – Next.js 13+ இல் ஒவ்வொரு fetch() அழைப்பும் ஒரு தனிப்பட்ட கோரிக்கை நினைவகத் தொகுப்பில் (per-request memory cache) சேமிக்கப்படுகிறது. revalidate விருப்பத்தைச் சேர்ப்பதன் மூலம், ஒரு குறிப்பிட்ட கால இடைவெளியின் பிறகு தரவைப் புதுப்பிக்குமாறு runtime-க்கு கூறலாம்; இது ஒரு 'hot API call'-ஐத் தேவைப்படும்போது மட்டுமே 'cold' ஆக மாற்றுகிறது.
  • Full-route cache – இந்த framework, முழுமையான ஒரு route-க்குத் தேவையான HTML மற்றும் தரவைச் சேமித்து வைக்கிறது. மீண்டும் வரும் பயனர்கள் உடனடி மாற்றத்தைக் (instant transition) காண்பார்கள், ஏனெனில் சர்வர் மீண்டும் render செய்வதைத் தவிர்க்கிறது.
  • ISR – பழைய பதிப்பு தொடர்ந்து பயனர்களுக்குச் சேவை செய்து கொண்டிருக்கும்போதே, பின்னணியில் நிலையான பக்கங்கள் (static pages) மீண்டும் உருவாக்கப்படுகின்றன. இது ஒவ்வொரு முறை உள்ளடக்கமும் மாறும்போது முழுமையாகத் தளம் மீண்டும் கட்டமைக்கப்படாமல் (full rebuild), ஒரு பெரிய தளத்தை நிலையாக வைத்திருக்க உதவுகிறது.
  • Server Component cache() – React-ன் cache helper, ஒரு தனிப்பட்ட கோரிக்கையின் கால அளவிற்குத் தேவையான கடினமான கணக்கீடுகள் அல்லது database இணைப்புகளை memoize செய்கிறது, இதனால் ஒரு பக்கத்தின் component tree-க்குள் ஒரே வேலையைத் திரும்பத் திரும்பச் செய்வதைத் தவிர்க்கலாம்.

இந்த cache-கள் "first-hit" சிக்கலைத் தீர்க்கின்றன, ஆனால் இவை இன்னும் Node process-க்குள்ளேயே உள்ளன. சர்வர் மற்றும் database-ஐப் பாதுகாக்க, caching-ஐ வெளிப்புறமாக நகர்த்தவும்.

நீங்கள் சேர்க்கக்கூடிய வெளிப்புற அடுக்குகள் (External layers)

அடுக்கு எதைச் சேமிக்கிறது பொதுவான கருவி எவ்வாறு உதவுகிறது
CDN Static assets, HTML, API JSON Cloudflare, Akamai, AWS CloudFront உள்ளடக்கத்தை edge இடங்களுக்கு நகர்த்தி, பயனருக்கான காத்திருப்பு நேரத்தைக் (round-trip) குறைக்கிறது
Reverse proxy Node-ஐச் சென்றடைவதற்கு முன் முழுப் பக்கப் பதில்கள் (responses) Nginx, Varnish சேமிக்கப்பட்ட பக்கங்களை நேரடியாக வழங்குகிறது, இதனால் Next.js instance-ன் சுமை குறைகிறது
Application-level cache கடினமான DB queries அல்லது API அழைப்புகளின் முடிவுகள் Redis, Memcached சர்வர் மறுதொடக்கம் செய்யப்பட்டாலும் அழியாத மற்றும் பல app instances-களில் பகிரப்படக்கூடிய வேகமான key-value store-ஐ வழங்குகிறது

ஒவ்வொரு அடுக்கும் மூல database-லிருந்து வெகு தொலைவில் உள்ளது, எனவே ஒரு நிலையில் cache இல்லையென்றால் (miss), அது அடுத்த நிலைக்குச் செல்லும்; இறுதியில், மிகவும் அவசியமான போது மட்டுமே அது database-ஐச் சென்றடையும்.

Cache-களைப் புத்துணர்ச்சியுடன் வைத்திருத்தல்

Invalidation (செல்லாததாக்குதல்) என்பது பெரும்பாலான குழுக்களைக் குழப்பமடையச் செய்யும் விஷயம். இதற்கென மூன்று நடைமுறை முறைகள் சிறப்பாகச் செயல்படுகின்றன:

  • Time-based (TTL) – ஒரு cache entry-க்கு ஒரு குறிப்பிட்ட காலாவதி நேரத்தை (expiration) நிர்ணயிக்கலாம். இதைத் தயார் செய்வது எளிது, ஆனால் timer முடியும் வரை பழைய தரவுகளை வழங்கக்கூடும்.
  • Event-driven – உள்ளடக்க மாற்றமடையும் போது webhook-ஐ வெளியிடும் உங்கள் CMS அல்லது ஏதேனும் தரவு மூலத்துடன் (data source) இணைத்துக் கொள்ளலாம். அந்த webhook தொடர்புடைய cache entry-யை நீக்கத் தூண்டும்.
  • Tag-based – fetch-களின் ஒரு குழுவிற்கு ஒரு தர்க்கரீதியான டேக் (logical tag) இணைக்கலாம் (உதாரணமாக, product-list). அந்த குழுவில் ஏதேனும் ஒரு பொருள் மாறும்போது, revalidateTag('product-list') என்ற ஒரே ஒரு அழைப்பு, அந்த டேக் உள்ள அனைத்து entry-களையும் நீக்கிவிடும்.

இந்த அணுகுமுறைகளைத் கலந்து பயன்படுத்துவதன் மூலம், தரவின் புத்துணர்ச்சிக்கும் (freshness) cache-hit விகிதத்திற்கும் இடையே சமநிலையைப் பேணலாம்.

பெரும்பாலான குழுக்களுக்குப் பயன்படும் படிநிலை (Hierarchy)

  1. Browser cache – Static assets (CSS, JS, images) நீண்ட max-age-ஐப் பெறுகின்றன, இதனால் பயனரின் சாதனம் மீண்டும் நெட்வொர்க்கிடம் கேட்கத் தேவையில்லை.
  2. CDN – Edge nodes முழுமையான HTML பக்கங்கள் மற்றும் API JSON-ஐ cache செய்கின்றன; இவை Next.js-இல் நீங்கள் அமைக்கும் Cache-Control headers-ஐப் பின்பற்றுகின்றன.
  3. Reverse proxy – ஒரு Nginx அல்லது Varnish instance, Next.js சர்வருக்கு முன்னால் அமர்ந்து, அரிதாகவே மாறும் routes-களுக்கு cache செய்யப்பட்ட பதில்களை வழங்குகிறது.
  4. Next.js internal cache – Framework-ன் data மற்றும் route cache-கள், per-request memoization மற்றும் ISR-ஐக் கையாளுகின்றன.
  5. Application cache – Redis, query parameters அல்லது tags மூலம் தேடப்படும் கடினமான database queries-ன் முடிவுகளைச் சேமிக்கிறது.
  6. Database – இதுவே உண்மையான தரவு ஆதாரம் (ultimate source of truth); மேலேயுள்ள அனைத்து நிலைகளிலும் cache இல்லையென்றால் (miss) மட்டுமே இது அணுகப்படும்.

ஒரு கோரிக்கை வரும்போது, அது இந்த வரிசையில் ஒவ்வொரு அடுக்காகச் செல்லும், ஏதேனும் ஒரு அடுக்கு அதற்குப் பதிலளிக்கும் வரை. மிக வேகமான பதில் வெற்றி பெறும், மேலும் அந்தப் பதில் எதிர்காலத் தேவைகளுக்காக மீண்டும் அந்தச் சங்கிலியில் (chain) சேமிக்கப்படும்.

அனைத்தையும் ஒருங்கிணைத்தல்

  1. உங்கள் API routes-களில் Cache-Control headers-ஐ அமைக்கவும்
  2. உங்கள் CDN-ஐத் தயார் செய்யவும் (Configure) – HTML மற்றும் JSON endpoints-களுக்கு edge caching-ஐச் செயல்படுத்தவும், மேலும் CDN ஆனது Cache-Control-ஐப் பின்பற்றுவதை உறுதி செய்யவும்.
  3. ஒரு reverse proxy-யை வரிசைப்படுத்தவும் (Deploy) – உங்கள் Next.js சர்வருக்கு முன்னால் Nginx-ஐ வைக்கவும்.
  4. Redis-ஐச் சேர்க்கவும் – கடினமான database queries-ன் முடிவுகளை cache செய்யவும்.
  5. உங்கள் components-களில் revalidateTag-ஐப் பயன்படுத்தவும் – ஒரு குறிப்பிட்ட டேக்கிற்கான Next.js internal cache-ஐ நீக்க revalidateTag-ஐ அழைக்கவும்.

சுருக்கம் (Takeaway)

Next.js-க்குள் இருக்கும் ஒரு தனி cache முதல் கோரிக்கையை வேகப்படுத்துகிறது, ஆனால் உண்மையான அளவிடுதல் திறன் (scalability) ஒரு ஒழுங்கமைக்கப்பட்ட அடுக்குத் தொகுப்பிலிருந்து (disciplined stack) வருகிறது: browser → CDN → reverse proxy → framework → Redis → database. ஒவ்வொரு அடுக்கையும் சரியாக அமைக்கவும், time, events மற்றும் tags மூலம் invalidation-ஐக் கையாளவும், மேலும் உங்கள் அளவீடுகளைக் (metrics) கவனிக்கவும். இதன் மூலம் உங்கள் backend போக்குவரத்து அதிகரிப்பைப் (traffic spikes) பொறுத்துத் தாங்கிக்கொள்ளும் அதே வேளையில், தாமத நேரம் (latency) குறைவாகவே இருக்கும்.