Next.js 15 geçiş yazısı, asenkron request API'lerini ve tersine çevrilen fetch önbellekleme varsayılanlarını işaret ediyor

Yükseltme günlük kullanımda karşılığını veriyor

dev.to'daki yazıya göre geliştirmede Turbopack'i etkinleştirmek, soğuk başlatmaları ve artımlı düzenlemeleri neredeyse anlık hale getirdi. Yazarın kendi ölçümlerinde derlemeler dört ile yedi kat daha hızlı tamamlandı ve büyük klasörlerde hot-module replacement gecikmesi 100 milisaniyenin altına düştü — yazar, bu rakamların gerçek projelerde yaklaşık yüzde 70–76 daha hızlı başlatmalara ilişkin kamuya açık raporlarla uyumlu olduğunu belirtiyor. Next.js 15 ayrıca React 19 desteği ve Partial Prerendering getiriyor; ekip bunları Server Components'a daha geniş bir geçişin parçası olarak kullandı.

Request API'leri artık asenkron

İlk kırıcı değişiklik, request'e özgü verileri okuyan API'leri kapsıyor: cookies(), headers(), draftMode ve params ile searchParams props'ları. Next.js 15'te bunlar Promise döndürüyor; dolayısıyla eski senkron çağrı noktaları derlenip dağıtılabiliyor, ardından runtime'da hafif hatalarla başarısız olabiliyor. Yazarın öne çıkardığı başarısızlık senaryosu, bir oturum çerezini senkron olarak okuyup döndürülen Promise hiç beklenmediği için sonradan hata fırlatan middleware veya auth mantığı.

Çözüm mekanik: çağıran fonksiyonu asenkron yapıp yardımcıyı await'lemek — cookies() beklenildiğinde çerez deposunu, params beklenildiğinde rota parametrelerini verir. Dinamik rotalarda server component imzaları artık params'ı Promise olarak tiplendiriyor. Next.js ekibi, dönüşümün büyük kısmını yapan bir codemod sunuyor (npx @next/codemod@canary next-async-request-api ile çalıştırılıyor), ancak yazar karmaşık desenlerin yine de manuel inceleme gerektirdiğini vurguluyor.

Fetch ve GET handler'ları varsayılan olarak önbelleğe alınmıyor

İkinci değişiklik önbelleklemeyi tersine çeviriyor: fetch çağrıları ve GET route handler'ları artık, önbellekleme açıkça tercih edilmedikçe no-store gibi davranıyor. Eski örtük önbelleklemeye bel bağlayan uygulamalar yükseltmeden sonra iki istenmeyen sonuçla karşılaşabilir — önbellekleme yanlış uygulanmışsa bayat veri, ya da önceden önbellekten sunulan istekler kaynağa gitmeye başladığında backend ve API trafiğinde ani sıçramalar.

Yeniden tercih etmek çağrı ya da rota bazında yapılıyor. Bireysel fetch'ler için yazı, statik ya da nadiren değişen veri için cache: 'force-cache''i, aralıklı revalidation için next: { revalidate: saniye }'yi işaret ediyor. Route handler'lar dynamic = 'force-static' veya bir revalidate değeri export edebilir. Yazarın pratik kuralı: gerçekten kullanıcıya özgü veriyi önbelleğe almadan bırakın, paylaşılan kaynakları ise bilinçli olarak önbelleğe alın.

İkincil kazanımlar ve işleyen bir kontrol listesi

Geçiş ayrıca daha fazla arayüzü Server Components'a taşıma ve Partial Prerendering'i benimseme fırsatı oldu; bu yaklaşım statik bir kabuğu hemen sunup dinamik parçaları akıtıyor ve yazar, uygulandığı yerlerde daha küçük client bundle'ları ile iyileşmiş p99 LCP bildiriyor.

Yazının kontrol listesi şu şekilde: next@15'e react@19 ve react-dom@19 ile birlikte yükseltin; codemod'u çalıştırın; generateMetadata dahil her request-kapsamlı çağrıyı denetleyin; her fetch ve GET rotası için önbelleklemeyi açıkça kararlaştırın; geliştirmede Turbopack'i etkinleştirin; auth, kişiselleştirme ve edge-runtime akışlarını smoke test edin; ve yayından sonra üretim backend trafiğini izleyin. Yazarın kendi denetiminde, bir middleware dosyası hiç şikâyet etmeden derlenip yayımlanmış ama beklenmeyen cookies() çağrılarından nadir runtime hataları üretmişti; düzeltmeden ve birkaç kritik fetch'e açık önbellek bayrakları eklendikten sonra LCP iyileşti ve bundle bütçeleri küçüldü.

Neden önemli

Değişen varsayılanlar kaza değil bilinçli bir tasarım olarak okunuyor: önbelleklemeyi açık bir karar haline getiriyor ve request verisinin nerede okunduğunu tam olarak görünür kılıyor. Bu uzun vadede daha sağlıklı, ama yükseltmeyi gerçek bir denetime dönüştürüyor. Next.js 14'teki ekipler, codemod artı her cookies(), headers(), params ve searchParams çağrı noktasının ve önceden örtük önbelleklemeye bel bağlamış her fetch'in üzerinden bir geçiş için zaman ayırmalı — aksi halde maliyetler runtime'daki auth hataları ve upstream servislerdeki açıklanamayan yük olarak ortaya çıkar.