Next.js 16, middleware'yi proxy olarak yeniden adlandırıyor ve eski dosya konvansiyonunu kullanımdan kaldırıyor

Middleware, proxy oluyor

Next.js 16, uzun süredir kullanılan middleware dosya konvansiyonunu kullanımdan kaldırıyor ve yerine proxy adında bir fonksiyon export eden proxy.ts adlı bir dosyayı getiriyor. dev.to'daki bir yazıya göre, framework'ün kendi dokümantasyonu durumu açıkça belirtiyor: middleware konvansiyonu kullanımdan kaldırıldı ve yeni adıyla anılıyor. Yükseltme yapan ekipler için göçün mekanik kısmı çok küçük — yazar, 16.2.4 sürümünü çalıştıran bir uygulamanın dosyanın ve export'un yeniden adlandırılmasından fazlasına ihtiyaç duymadığını bildiriyor.

Yazıya göre asıl anlamlı iş, yeniden adlandırma değil, export'un altındaki, fonksiyonun hangi istekleri göreceğini belirleyen config objesi.

Matcher bir doğruluk kararıdır

Yazıda alıntılanan Next.js dokümantasyonu varsayılan davranış konusunda net: matcher olmadan proxy, _next/static ve _next/image altındaki framework asset'leri ve public dizininden sunulan her şey dahil olmak üzere her istekte çalışıyor. Bu, matcher'ı isteğe bağlı bir performans ayarından çekirdek bir tasarım kararına dönüştürüyor.

Yazının kendi matcher'ı, dört yol kategorisini hariç tutan tek bir negatif lookahead: framework'ün asset yolları, tarayıcıların otomatik olarak istediği favicon.ico yolu, uygulamanın webhook endpoint'leri ve yaygın bir görsel uzantısıyla biten herhangi bir yol.

Son dalgtaki anchor (çapa) bilinçli. Dize sonu anchor'u olmayan bir son ek deseni, yalnızca içinde ".svg" geçen yolları da hariç tutardı — ref=logo.svg gibi bir query string'e sahip bir URL, sessizce session yenilemelerini almayı keserdi. Eşleşmeyi anchor'lamak, kuralın URL'de herhangi bir yerde geçen dizeden ziyade hangi dosyanın istendiğiyle ilgili olmasını sağlıyor.

Webhook'ların neden hariç tutulduğu

Uygulamanın /api yolları altındaki diğer her şey, kendi frontend'i tarafından bir token veya cookie ile çağrılıyor; webhook yolları ise Stripe ve Resend tarafından çağrılıyor. Yazı bunları hariç tutmak için üç gerekçe veriyor. Hiçbir tarayıcı devrede olmadığı için, o yanıtlardaki CORS header'ları bir işe yaramıyor. Yenilenecek bir kullanıcı oturumu olmadığı için session refresher çalıştırıldığında her teslimat ve yeniden denemede bir Supabase client kurulur ve var olmayan cookieler okunurdu. Bu yolların kimlik doğrulaması ise ham gövde üzerindeki bir HMAC imzası ve bu, route handler'a değil ondan önce çalışan bir fonksiyona aittir.

Bu hariç tutma bir tarayıcıdan gözlemlenebilir: sıradan bir API yoluna yapılan cross-origin fetch okunabilir bir status ile sonuçlanırken, bir webhook yoluna yapılan aynı fetch, o yolda hiçbir şey preflight'e yanıt vermediği için bir ağ hatasıyla başarısız oluyor. Yazının altını çizdiği bir incelik ise response objesindeki allow-origin header'ının null görünmesi — o header asla JavaScript'e açık değildir ve mevcut olduğunun kanıtı, isteğin hiç değilse çözülmüş olmasıdır.

Sıralama ve fail open davranışı

Fonksiyon içindeki işlem sırası göründüğünden daha önemli. Bir preflight OPTIONS isteği, döndürmeye değer cookieler olmayan bir politika sorusudur; bu nedenle hemen, yalnızca header'lardan oluşturulmuş şekilde döner ve asla bir auth client oluşturmaz. Session yenilemesi önce çalışsaydı, her tarayıcı API çağrısı tek yerine iki yenileme bedeli öderdi.

Session yenilemenin kendisi, bir Supabase kesintisi veya hatalı yapılandırılmış bir ortam değişkeninin her eşleşen isteği başarısız kılmak yerine hiçbir şey yenilememesi için sarılmış durumda — ki bu fiilen siteyi devre dışı bırakırdı. Yazar, bunun ne konusunda fail open olduğuna dikkat ediyor: bir oturumu yenilemek konusunda, bir oturumu yetkilendirmek konusunda değil. Kullanıcı gerektiren yollar o kullanıcıyı yine kendileri çözer ve aksi halde 401 döner.

Edge deployment uyarısı

Dokümantasyon, proxy'nin render kodundan ayrı çalışması gerektiğini ve optimize edilmiş kurulumlarda CDN'e deploy edilebileceğini, paylaşılan modüllere veya globallere güvenilmemesini öneriyor. Yazıdaki proxy iki yerel modül import ediyor ve bunlardan biri izin verilen origin kümesini, modül başlatılmasında bir kez ortam değişkenlerinden ayrıştırıyor. Bu, uyarının güvenli tarafında duruyor; ancak yalnızca o state salt okunur ve her instance'da aynı olduğu için. O kapsamda bir sayaç, rate-limit bucket'ı veya memo, potansiyel olarak düzinelerce izole edge instance'ı arasında paylaşılır ve aralıklı, yeniden üretilmesi zor bug'lara yol açardı.

Neden önemli

middleware.ts kullanan her Next.js kod tabanı, 16'ya geçerken bu yeniden adlandırmayı yapmak zorunda; değişikliğin kendisi mekanik olsa da, her eşleşen istekten önce çalışan kodun nadir bir gözden geçirilmesini zorunlu kılıyor. O katmandaki hatalar sistemiktir: fazla geniş bir matcher statik asset'lerde iş israfı yapar, anchor'lanmamış bir desen meşru yollarda işi sessizce atlar ve hata fırlatan bir yardımcı, tüm bir sitedeki sayfaları devre dışı bırakabilir. Proxy'nin ayrı, muhtemelen CDN edge'ine deployment konumlandırması da statelessness için çıtayı yükseltiyor — middleware render kodunun yanında çalışırken geçerli olan varsayımlar, izole instance'larda çalıştığında geçerli olmayabilir.