Next.js ISR ve Talep Üzerine Revalidation Rehberi

Next.js'teki Incremental Static Regeneration (ISR), sayfaları build zamanında önceden oluşturup arka planda güncelleyerek stale-while-revalidate mantığıyla çalışır; kullanıcılar hiçbir zaman yavaş bir render için beklemez ama belirli bir süre eski içerik görebilir. Zaman tabanlı ISR (revalidate: 3600 gibi) öngörülebilir aralıklarla değişen ve hafif eskimenin sorun olmadığı içerikler için iyi çalışırken, acil bir fiyat değişikliği veya içerik düzeltmesi gibi durumlarda revalidation penceresi dolana kadar güncelleme görünmeyebilir — bu da editoryal iş akışlarında ciddi bir sorun yaratır.

Bu noktada devreye giren on-demand revalidation, revalidatePath ve revalidateTag fonksiyonları aracılığıyla belirli sayfaları veya cache tag'lerini programatik olarak geçersiz kılmayı mümkün kılar. CMS webhook'ları (Contentful, Sanity, Notion CMS vb.) içerik yayınlandığında bir API endpoint'ini tetikleyerek ilgili tag'leri revalidate edebilir; böylece hem tekil bir yazı hem de listeleme sayfası tek seferde güncellenir. Pratikte önerilen yaklaşım, zaman tabanlı revalidation'ı bir güvenlik ağı olarak tutup (webhook başarısız olsa bile cache eninde sonunda tazelenir), kritik güncellemeler için tag tabanlı on-demand revalidation'ı ana mekanizma olarak kullanmaktır.

Yaygın hatalar arasında revalidate: 0 kullanarak cache'i tamamen devre dışı bırakmak (bunun yerine revalidate: false tercih edilmeli), revalidation endpoint'ini bir secret ile korumamak (DoS riski), layout seviyesinde aşırı geniş revalidation yapmak ve webhook hatalarını izlememek sayılabiliyor. Mühendisler için önemli nokta, revalidateTag çağrısının anında tazelik garanti etmediği; sadece bir sonraki isteğin yeniden oluşturmayı tetiklediğidir.