proxy.ts (Next.js ara yazılımının halefi)

Kısaca: Next.js 16’da middleware.ts, proxy.ts olarak yeniden adlandırıldı — projede iki dosyadan yalnızca biri bulunabilir, aksi hâlde derleme bozulur.

Biraz daha ayrıntılı: Eski ara yazılım gibi asıl işlemeden/yönlendirmeden önce çalışır ve istekleri yeniden yazabilir veya yönlendirebilir, ya da kendi yanıtıyla erken sonlandırabilir (örneğin bir hız sınırı aşıldığında 429). Eşleştirici (config.matcher) işlevin hangi yollar için hiç çağrılacağını belirler.

Bizim bağlamımız: Emzett’te proxy.ts bilinçli olarak tek dosyada İKİ görevi üstlenir: küresel hız sınırlama (geniş eşleştirici, formu olmayan salt okunur sayfalar dışında hemen her istek) ve korumalı alanlar için hafif bir kimlik doğrulama yönlendirmesi (yalnızca bir “çerez var” kontrolü — veri tabanına karşı tam oturum doğrulaması yine sunucuda getCurrentUser() içinde yapılır). Proje kökündeki AGENTS.md’ye göre, bilinçli olarak belgelenmiş bir Next.js 16 tuzağıdır, çünkü eğitim bilgisi burada hâlâ middleware.ts varsayar.

Ayrıntılı

Performans kaldıracı olarak eşleştirici

Dışa aktarılan config içindeki matcher performans için belirleyicidir: işlev HER istekte (tüm statik varlıklar dahil) çalışırsa gereksiz uç işlev çağrılarına mal olur — her çağrı ek gecikme ve çoğu barındırma platformunda ek maliyet anlamına gelir. Tipik bir kalıp, ara yazılımdan hiç geçmesi gerekmeyenleri özellikle dışlar:

export const config = {
  matcher: [
    "/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp|ico)$).*)",
  ],
};

Dahili olarak eşleştirici bir düzenli ifadeye derlenir ve HER istekten ÖNCE denetlenir — yani asıl ara yazılım işlevi sonuç olarak çalıştırılmasa bile çalışır. Statik eşleştirici dizgileri (yukarıdaki gibi), dizi yöntemleriyle dinamik olarak birleştirilenlerden daha performanslıdır, çünkü Next.js bunları derleme zamanında tam olarak analiz edebilir.

Yeniden yazmak, yönlendirmek veya sonlandırmak

Ara yazılım işlevi içinde yanıt vermenin esasen üç yolu vardır: NextResponse.next() isteğin değişmeden devam etmesine izin verir, NextResponse.redirect(url) tarayıcıya gerçek bir HTTP yönlendirmesi gönderir (adres çubuğundaki URL gözle görülür biçimde değişir) ve NextResponse.rewrite(url) içeriği tarayıcı fark etmeden başka bir dahili URL’den sunar (adres çubuğu değişmez). Kimlik doğrulama yönlendirmeleri için genellikle redirect() doğrudur (kullanıcı örneğin /login sayfasına düştüğünü görmelidir), rewrite() ise statik dışa aktarımlara veya A/B test varyantlarına dahili eşleme için daha uygundur.

next.config.ts’in rewrites() ile etkileşim

Önemli, kolay gözden kaçan bir nokta: next.config.ts’in rewrites() fonksiyonu ile ara yazılım, istek işlemenin farklı aşamalarında çalışır — bir yol bir rewrite ile tamamen farklı, bağımsız statik içeriğe (örneğin önceden derlenmiş statik bir site dışa aktarımına) işaret ediyor ama ara yazılım eşleştiricisi hâlâ onu kapsıyorsa, o sayfanın sonradan yüklenen TÜM varlıkları (CSS, JS, JSON) aynı ara yazılım mantığından tek tek geçer — küresel uygulanan hız sınırlamasıyla bu, tek bir “sayfa görüntülemesi” için sınırı kolayca aşabilir, çünkü bir yerine onlarca ayrı istek sayılır. O zaman bu tür yollar için eşleştiricide veya kendi ara yazılım mantığında açık bir istisna gerekir.

Uç çalışma zamanının sınırları

Ara yazılım/proxy.ts varsayılan olarak tam bir Node.js ortamında değil, bir uç çalışma zamanında çalışır — birçok Node API’si (örneğin dosya sistemine yerel fs erişimi, bazı veri tabanı sürücüleri) orada kullanılamaz. Bu, proxy.ts içindeki kimlik doğrulama kontrollerinin neden genellikle (gerçek bir veri tabanı sorgusu yerine) yalnızca hafif bir “çerez var” kontrolü yaptığının nedenlerinden biridir; asıl, eksiksiz oturum doğrulaması ise yine tam Node.js ortamına sahip sıradan bir Sunucu Bileşeninde veya rota işleyicisinde yapılır.

Ayrıca bak: Next.js App Router, Hız sınırlama, Açık yönlendirme