- Next.js middleware’i sınırlı günlükleme yapılandırması sunuyor ve varsayılan günlükleme yalnızca geliştirme ortamında etkin olduğundan üretim ortamında sorun takibi zorlaşıyor
- Middleware’de yalnızca header aktarılabiliyor ve birden fazla middleware chaining mümkün olmadığından karmaşık günlükleme uygulamaları kısıtlanıyor
- AsyncLocalStorage ile yapılan günlükleme Edge runtime’da beklenmedik davranışlar gösteriyor ve sayfa ile middleware arasında context paylaşımı düzgün çalışmıyor
- Custom server kullanılsa bile günlükleme sorunlarını çözmek zor ve Next.js’in tasarım kısıtları geliştiriciyi belirli bir yaklaşıma zorluyor
- Vercel’in SvelteKit’i esnek middleware ve veri aktarma mekanizmaları sunarak Next.js’e göre daha geliştirici dostu bir tasarım ortaya koyuyor
Next.js’te günlükleme sorununun arka planı
- Next.js servisi işletirken production log kaydı denendiğinde, varsayılan log özelliğinin yalnızca geliştirme ortamında etkin olduğu fark ediliyor
- Üretim ortamına uygun bir günlükleme sistemi uygulaması gerektiğinde Next.js’in sınırlarıyla karşılaşılıyor
Middleware’in sınırlamaları
- Resmî belgelere göre middleware routing’den önce çalışır ve kimlik doğrulama, günlükleme, yönlendirme gibi işlevleri uygulamak için uygundur
- Pratikte middleware’e aktarılabilecek parametreler 4 ile sınırlıdır ve fiilen yalnızca header’lar taşınabilir
- Birden fazla middleware’i chaining ile bağlayan ya da birleştiren yapı desteklenmiyor
- Node.js tarafında Express gibi araçlarda yerleşik middleware pratikleri bulunmasına rağmen, Next.js’te bunları düzgün şekilde uygulamak mümkün değildir
AsyncLocalStorage ile aşma denemesi
- pino ve AsyncLocalStorage kullanılarak middleware seviyesinde logging instance’ını yönetme denemesi yapılıyor
- Middleware’de her istek için benzersiz context ile log saklamak mümkün olsa da, bunun yalnızca tarayıcı ortamında düzgün çalıştığı görülüyor
- Bunun nedeni Next.js middleware’inin varsayılan olarak edge runtime kullanması ve nodejs runtime’a ayarlansa bile proje durumuna göre kararsız davranabilmesi
Sayfa bileşenlerindeki aksaklık
- Gerçek sayfa ya da layout bileşenlerinde günlükleme fonksiyonu çağrıldığında, logger() null döndürüyor
- Middleware’de oluşturulan logger context’inin asenkron render bağlamına aktarılmaması gibi yapısal bir sorun bulunuyor
- Çözüm olarak geriye yalnızca requestId gibi günlükleme bilgisini header’a koyup aktarma yöntemi kalıyor; bu da kodu karmaşıklaştırıyor ve import yapısını karıştırıyor
- Client component’lerde de benzer yapısal ayrımların ayrıca ele alınması gerekiyor
Custom server ekleme denemesi
- Resmî belgelerdeki custom server örneği izlenerek http.createServer ve next.js’in app.getRequestHandler kullanımı deneniyor
- Bu ortamda AsyncLocalStorage yeniden kullanılmak istense de, middleware–sayfa–custom server arasında context bağlantısı kurulamaması sorunu tekrar ediyor
- Temelde Next.js içinde yalnızca kendisi AsyncLocalStorage’ı düzgün kullanabiliyor ve geliştiriciye aynı yetki verilmiyor
- Middleware’den sayfaya aktarılabilecek yollar fiilen sadece yanıt header’ında değişiklik yapmak ve redirect/rewrite yoluna taşımak ile sınırlı
- Kullanıcı açısından esnek genişletme ya da custom context aktarmak son derece zor
SvelteKit ile karşılaştırma
- Vercel’in SvelteKit’i Next.js’ten daha esnek bir middleware sistemi sunuyor
- event.locals nesnesi üzerinden istek verileri serbestçe aktarılabiliyor
- Birden fazla handle fonksiyonu tanımlanıp chaining yapılabildiği için karmaşık mantıklar kolay uygulanabiliyor
- SvelteKit, geliştirici dostu bir tasarım sergiliyor ve bu yönüyle Next.js’in kısıtlarıyla tezat oluşturuyor
- SvelteKit, Vercel’in ürünü olmasına rağmen Next.js’e göre ikincil bir proje sayılmasına karşın daha iyi bir deneyim sunuyor
Issue tracker ve ekosistem kültürüne eleştiri
- Next.js’in resmî GitHub issue tracker’ında kullanıcı geri bildirimlerine neredeyse hiç yanıt verilmediği durumlar yaşanıyor
- Popüler issue’lar ya da bug’lar bile uzun süre yanıt ya da çözüm olmadan bırakılabiliyor
- Minimal yeniden üretim kodu hazırlanıp issue açılsa bile gerçek bir yanıt veya takip eden bir işlem gelmiyor
Sonuç ve değerlendirme
- Next.js’te görülen bug’lar ve yapısal sınırlar, tekrar tekrar geliştirici verimliliğine zarar veriyor ve temel iyileştirmeler gerektiriyor
- Diğer framework’lerle (SvelteKit vb.) karşılaştırıldığında, ana ürün olmasına rağmen Next.js kullanılabilirlikte geride kalıyor
- Şimdilik Next.js’i değiştirme planı zor görünse de, gelecekteki projelerde başka seçenekleri değerlendirme isteği doğuyor
7 yorum
React'in üretkenliği düşürdüğünü hâlâ fark etmemiş olmalılar.
Bu kez sadece kişisel ilgimle, aslında geliştirdiğim alanla hiç alakası olmayan bir alan olan web geliştirmeyi denedim. next.js v15 app router ile bir ilan panosu yaptım ama... Böyle yazılar gördükçe web tarafında yeni bir şey deneme hevesim biraz kırılıyor gibi. Ekosistem neden bu kadar istikrarsız? Böyle giderse yine yeni bir şey çıkınca herkes akın edip biraz kullanacak, sonra söylenip başka bir şey mi arayacak? Web geliştirme tarafı gerçekten zor olmalı.
Sektörün doğası gereği değişimin hızlı olması bir yandan avantaj ama bir yandan da dezavantaj tabii haha. Ama metindeki sorunun temel nedeni aslında Vercel'in ortalığı karıştırması. Front-end yapacaksanız Vercel'e karşı biraz dikkatli olmanız gerekir, hüzünlü.
Kariyerime web ile başladığım için olabilir ama web’de (özellikle frontend tarafında) geliştirme zaten baştan beri biraz öyle bir tatla yapılıyor haha
Hızlı hızlı, sürekli değişen bir tat...
JS tarafı biraz öyle bir his veriyor. Güzel denilen bir sürü şey var ama hepsinin az çok bir sorunu var ve modaya göre çok hızlı değişiyor...
Bana öyle gelmesinin nedeni ağırlıklı olarak Java, EJB ve Struts ile çalışmış olmam da olabilir tabii.
Hacker News görüşü
%100 katılıyorum; ben de aynı sorunları yaşadım ve bundan sonra Next.js'i asla kullanmayacağım, şirketteki tüm ekiplere de başka alternatifler kullanmalarını önereceğim
Next.js, projelerin %99.9999'unda gerekmeyen devasa bir soyutlama katmanına sahip; gerçekten buna ihtiyaç duyan az sayıdaki durumda ise alt seviye parçalardan özel bir çözüm kurmanın daha iyi olduğunu düşünüyorum
Kullandığım teknolojiler arasında Next.js açık ara en kötüsüydü
Bu şekilde düşünen tek kişi olmadığımı görmek gerçekten büyük rahatlama
Next.js ile orta düzey karmaşıklıkta, gelir üreten bir production uygulaması yaptım; başta Vercel ve Google Firebase kullandım, sonra kendi kendime host etmeye geçip Pocketbase ile değiştirdim
İyi bir deneyim yaşadığım tek şey Pocketbase'ti, geri kalan her şey gerçekten korkunçtu
Bitmek bilmeyen karmaşıklık, durmadan gelen breaking change'ler, ulaşması zor dokümantasyon; hiçbir şey kolay değildi
Son 5 yıldaki FE trendlerini geri sarıp, o dönemde var olan teknolojileri düzgün öğretmeye odaklansaydık bugün olduğumuzdan daha iyi bir yerde olacağımıza eminim
Oldukça karmaşık React frontend'leri de yaptım; React'i de çok sevdiğim söylenemez ama Next.js daha da kötüydü
Go ve vanilla JS ile CMS de yaptım; DX biraz daha zayıf olabilir ama en azından ne olup bittiğini gerçekten bildiğim hissi vardı
React ve Next.js'te neden 6 yıl sonra bile her zaman ne olacağını tahmin etmek zorunda olduğumuzu bilmiyorum
Framework'ün dolanmalarını çözebilecek deneyim kazandım ama genel olarak fazla dağınık ve kötü tasarlanmış hissettiriyor
Go'da ilk 6 ay dışında hiç şaşırmadım ve eski codebase'ler hâlâ sapasağlam
Frontend tarafında da böyle bir deneyim yaratılamaması üzücü
Benim deneyimime göre Next.js'in pürüzlü tarafları bug değil, özellik
Her şey kullanıcının pes etmesini ve Vercel hosting'e kilitlenmesini sağlamak için tasarlanmış gibi geliyor
Bundan sonra durumun daha da kötüleşeceğini düşünüyorum
Şu anda PluralSight gibi online eğitimler bile React derslerinde yalnızca Next.js'i iteliyor
Bunun neden böyle olduğunu bilmiyorum ama buraya geldik
Benim için Sharepoint daha kötü bir anı olduğu için, Next.js en kötü ikinci şey
Next.js'te en sinir bozucu olan şey, Rails, Wordpress, Meteor gibi full-stack framework'ler gibi her şeyi sağlıyormuş gibi davranırken, aslında yalnızca en sıkıcı ve en sınırlı kısımlarda (middleware, image resizing, SSR vb.) fikir sahibi olması; gerçekten değerli kararlarıysa (veritabanı, ORM, iletişim protokolü vb.) kullanıcıya bırakması
Gerçekte Rails/Wordpress/Meteor'dan oldukça farklı ve framework'ün altyapıyı tanımlaması gerekirken burada altyapı framework'ü belirliyor
Dashboard'umda "Fluid Active CPU" ve "ISR Writes" en yüksek kullanım kalemleri ve ayda $20 ödeyip %100'ü aşmamasını ummaktan başka bir şey yapmıyorum
Kalem adları Star Trek'ten çıkmış gibi teknik terimlerle dolu ve sonraki major sürümde yine değişecek gibi durduğu için öğrenmek bile istemiyorum
Eskiden Zeit'e hayran olan tanıdıklarımın epey kısmı sonunda projelerini ve müşterilerini başka yerlere taşıdı
Vercel bana bir sonraki major release'de neyi değiştirmesi gerektiğini sorsa, ancak "App Router dahil ondan sonraki her karar yanlıştı" diyebilirim
Bunun nasıl toparlanabileceğini bilmiyorum
Bence Next.js'in pek çok sorunu, kodun gerçekte nerede çalıştığını tam olarak bilmemekten kaynaklanıyor
Browser, middleware, edge ve node, SSR gibi her şey birbirine karışınca muazzam bir karmaşıklık oluşuyor
Bunun mantıklı olduğu zorlayıcı durumlar şunlar
Global kullanıcı kitlesine sahip bir B2C hizmet işletip edge semantiğiyle gecikmeyi azaltmak istediğinizde
Vercel'in pahalı hosting'ini kullanmaya hazır olduğunuzda
Background job gerektirmeyen, çok karmaşık olmayan bir mimari yeterli olduğunda
Bunun dışında react-vite SPA ya da Rails gibi geleneksel SSR çok daha güvenli seçenekler
Ben yukarıdaki koşullara da katılmıyorum
Next.js'e uygun olsa bile, üretkenlik ve bakım kolaylığındaki düşüş bunun karşılığını hiç vermiyor gibi
Ben Gleam'in Lustre'ını kullanıyorum ve geri dönmeyi düşünmüyorum
Elm kurucusunun keynote'u da bana göre Next.js'e karşı bir örnek
https://www.youtube.com/watch?v=sl1UQXgtepE
Vercel'i modern web'in kanseri olarak görüyorum
Her framework ekosistemine sızıp ücretli plan satmak için kötüye kullanıyor, bir yandan da açık kaynak, rekabet ve web'in gelişimini önemsiyormuş gibi yapıyor
İlk koşul geçerli olsa bile, Vercel ve SSR kullanmanın performans darboğazlarını ortadan kaldırdığını düşünmek zor
Performans düşüşlerinin çoğu aşırı büyük bundle boyutları, sayısız yavaş API çağrısı gibi temel nedenlerden geliyor
Temel profiling, optimizasyon ve sadeleştirme yapmak, mimariyi karmaşıklaştırmaktan çok daha etkili
"Kodun nerede çalıştığını bilmeme sorunu" kısmına katılıyorum
Eskiden JavaScript'in her şeye yetmesi bana avantaj gibi gelirdi ama şimdi bunun asıl sorun olduğunu düşünüyorum
Bizim şirket Inertia.js + Vue kullanıyor; genel yapı çok daha basit, frontend render gücü korunuyor ama routing %100 server tarafında ve ayrıca API da gerekmiyor
React ve Svelte ile de Inertia kullanılabiliyor
Başta Nuxt kullandık ama backend server ile frontend server'ı aynı anda işletmeyi gerektirecek kadar karmaşıktı ve kodun nerede çalıştığını anlamak zordu
Şimdi PHP server'da, JS browser'da ayrımı sayesinde hiç düşünmemiz gerekmiyor
Bu bizim için çok büyük avantaj
Bence ana fikir çok iyi özetlenmiş
Vercel; React Server Components, Partial Pre-rendering, Edge server'lar, streaming gibi şeylerle performans optimizasyonu peşinde
Tuhaf tasarım ve API kararlarının tamamı buradan geliyor
Gereken durumlarda bunlar yardımcı olabilir ama edge function'ların bir kısmıyla SSR'ı yerinde kullanmak bile büyük fark yaratabilir
Geri bildirim bıraktığınız için teşekkürler
Middleware tarafındaki DX sorunlarının farkındayız ve 15.5 sürümünde Node runtime desteğini önemli bir ilerleme olarak sunduk[1]
Geri dönme şansım olsaydı adını Routing Middleware ya da Routing Handler gibi bir şeye çevirirdim; çünkü aslında routing aşamasında CDN edge'e devredilebilen gelişmiş bir escape hatch olarak düşünülmüştü
Log gerekiyorsa OpenTelemetry kullanarak instrumentation.ts pratiğine[2] uygun biçimde ele alabilirsiniz
[1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable
[2] https://nextjs.org/docs/app/api-reference/file-conventions/instrumentation
Yanıt için teşekkürler
Ama instrumentation ve observability'den söz etmeniz, basit bir log sorununu yine başka bir karmaşık katmanla çözmeye çalışıyormuşsunuz gibi geliyor
Her uygulamanın OpenTelemetry'ye ihtiyacı yok
logger().info() gibi sıradan bir yöntemin neden çalışmadığını anlamıyorum
Diğer dillerde ve framework'lerde olan bir şeyin burada neden bu kadar zor olduğunu kavrayamıyorum
Buradaki hava olumsuz olduğu için önce şunu söylemek istiyorum: Next.js gerçek amaçları için gayet iyi, güçlü bir yazılım
Milyonlarca siteyi taşıyan bir yazılımı iyi şekilde yaptıklarını düşünüyorum
Sorun, ayrıntılı referans ve dokümantasyon eksikliğinden kaynaklanıyor; dokümanlar nelerin var olduğunu söylüyor ama bunların gerçekte nasıl kullanıldığını, ne zaman çalıştığını, yaygın tuzakları vb. pek anlatmıyor
Yeni başlayanlara dost ama karmaşık runtime bağlamları ve derived complexity konusunda rehberlik eksik
Bu bugün birçok projede görülen bir eğilim
User friendly olmakla ayrıntılı açıklama arasında denge kurmak çok zor
Umarım gelişmeye devam eder
Sözde tek cümlelik özet şu
Bu yazının yazarı, domain'ler arasındaki farkı ayırt edemeyip her yerde aynı şekilde fonksiyon çağırmaya çalışmış
Next.js'in hatası, aslında farklı doğaya sahip domain'leri zorla birleştirmeye çalışmasından doğuyor
Edge, SSR, Node ve client tarafını bu şekilde birbirine karıştırırsanız karmaşıklık sadece artar
Bu dokümantasyonla da çözülemez, hatta daha fazla kafa karıştırır
Bir keresinde bana Reddit yorumlarında instrumentation yöntemi önerilmişti
Aynı zamanlarda opentelemetry'yi Next'e kurarken dokümantasyon farklı olsaydı, bu deneyimden sonra bir blog yazısı yazardım
Bu sizin suçunuz değil ama neredeyse tüm opentelemetry paketlerinde deneysel ibaresi olduğu için production'da güven vermiyor
pino instrumentation kurmak da çok zordu
pino'nun düzgün çalışması için serverExternalPackages'e eklenmesi gerekiyor
Otomatik ölçümleme import sırasına aşırı duyarlıydı ve yalnızca pino'nun default export'u ölçümleniyordu
Modül yerel değişkenleri de beklediğim gibi çalışmadığı için globalThis kullanmak zorunda kaldım
Buna rağmen sonunda https://github.com/vercel/next.js/issues/80445 sorununa da takıldım
Sonuçta çalıştı ama kurulum gerçekten çok uğraştırıcıydı
Bu deneyimi manuel router yüzünden yaşadım (=vercel/otel kullanmıyorum)
Server-side middleware desteği eklenecek bir karar alındıysa, neden hâlâ middleware chain'i, yani birden fazla fonksiyonun bağlanmasını desteklemiyorlar ve yalnızca bir tane kabul ediyorlar anlamıyorum
Diğer server framework'lerinde bunun hepsi var
"Birden fazla middleware chain'i mümkün değil" denmesinin gerçek olup olmadığından şüpheliyim
https://nextjs.org/docs/messages/nested-middleware
Birden fazlası varsa tek dosyada birleştirip çalıştırmanız gerekiyormuş; inanması gerçekten güç
Doğru okuduysam, Next.js birden fazla dosyada yapılandırmak yerine tek dosyada birleştirin mi diyor?
Scoping sorunları yüzünden mi birden fazla dosya kullanmak zor? Bir framework için çok saçma bir talep
Bu saçma kararların çoğunun framework'ün yararına değil, Vercel'in çıkarına daha uygun olduğu şüphesini üzerimden atamıyorum
Next.js'i ilk gördüğümde hemen Meteor.js aklıma geldi
Öğrenmek için kişisel projelerde epey yatırım yaptım ama aşırı soyutlama ve katılık yüzünden prototipin ötesine geçmek zordu
Bu tür "bataryalar dahil" çözümler sürekli çıkıyor çünkü ilk kurulumları rahat
Yakın zamanda Hacker News'te Laravel vs Symphony karşılaştırmasında da iş karmaşıklaşınca dağıldığı konuşuluyordu
Bu yaklaşımı, eski NodeJS/React SPA tarzında her şeyi bileşen bileşen sizin kurduğunuz yapıyla karşılaştırırsak; orada her parça daha düşük seviye bir soyutlama olarak bağımsız kaldığı için esneklik daha yüksek ve parçaları değiştirmek daha kolay
Eksileri var ama overengineering'den, yani üst üste birikmiş karmaşıklıktan daha pürüzsüz
Bataryalar dahil yaklaşımın neden popüler olduğunu tamamen anlıyorum
Çünkü çeşitli araç ve kütüphaneleri bir araya getirip uyumlu hale getirmek gerçekten çok zahmetli
Bu tür kompozisyon temelli yaklaşım, işi iyi kuracak daha deneyimli birine ihtiyaç duyuyor
Ben asp.net'e alışığım; startup odaklı geliştirici topluluklarında kötü konuşulduğu çok olur ama gerçekte son derece iyi tasarlanmış bir framework
Bataryalar dahil ama istediğim an framework'ün dışına çıkıp override edebildim ve hiçbir zaman framework'le kavga ediyormuşum gibi hissetmedim
Blazor Server ve Blazor Webasm ile frontend'i C# ile yazabiliyorsunuz; ikisi de kendi alanlarında iç paneller ya da SaaS uygulamaları için iyi
En önemlisi, geleneksel server-side rendering ile de her şeyi çözmek mümkün
Web framework'lerinden memnun olmayan herkese denemesini öneririm
Artık cross-platform desteği de iyi, hızlı da, öğrenmesi de kolay
Bir learning curve var ama modül yapısını anladıktan sonra istediğim gibi override etmek kolay oldu
Diğer framework'lere kıyasla sınırlarına çarptığım anlar gerçekten çok daha azdı
NodeJS/React SPA'deki gibi parçaları bir araya getirilen yapı, Angular tarafında daha az yaygın
Angular bir kütüphane değil, framework olduğu için gereken çoğu şeyi içinde getiriyor
(RxJS'nin bir learning curve'ü var ama temellerini öğrendiğinizde fazlasıyla güçlü)
Genelde SPA geliştirirken framework'le boğuşma hissi pek yaşamadım
Dokümantasyon ve eğitimler de, Tour of Heroes dahil, gerçekten çok iyi
https://v17.angular.io/tutorial/tour-of-heroes
En güncel dokümanlar https://angular.dev/ adresinde
Laravel, overengineered soyutlamanın başarılı örneği
Laravel sayesinde production'da hiç pişman olmadım
Konudan biraz bağımsız ama birbirine tam uymayan küçük araç ve kütüphaneleri sürekli birbirine bağlamak tam anlamıyla benim işim
Ekibimiz küçük olduğu için güncel tutma ve bakım için sürekli çok büyük zaman harcıyoruz; yıllar önce desteği kesilmiş paketlerle ilgili sorunlar da sık sık çıkıyor
Deneyimin kendisinden bağımsız olarak, sistem kurmanın ilk zamanı ve bakım maliyeti insanın düşündüğünden çok daha büyük
Bizzat yaptığımda, Node ile parça parça kütüphane birleştirmek yerine Rails'in üretkenliğinin 10 kat fazla olduğunu hissettim
Sorun ancak framework'ün temeline ve felsefesine itirazınız varsa çıkıyor; örneğin ActiveRecord'dan hoşlanmıyorsanız
"Karmaşıklık artınca her şey bozulur" demek teknik yetersizlik göstergesi
Ben React'i çok savunan biriyim ve class component'ten hooks'a geçişi de beğeniyorum
Ama ne zaman Next.js kullansam, tam olarak nerede işlerin yanlış gittiğini anlayamaz hale geliyorum
Bir sürü framework'ü ve sıra dışı dili seviyorum ama Next.js kadar hata mesajlarının yarısını bile anlamadığım tek deneyim bu oldu
Özellikle garip hydration sorunlarıyla harcadığım zaman inanılmaz fazlaydı
Ben React ya da Next.js kullanmıyorum
Kişisel olarak HTML+CSS üzerine biraz vanilla JS eklemeyi tercih ediyorum
Basit bir Next.js landing page'in Firefox'ta bozulduğunu da yaşadım
Daha kötüsü, tüm içeriğin üstünde siyah ekran ve beyaz yazıyla sadece "An application client side error has occurred" mesajının görünmesiydi
Basit bir landing page'in bile render edilememesi şaşırtıcıydı ve bunun JS frontend framework'ünden kaynaklandığını anladıktan sonra sadece "eh, beklenir" dedim
Kullanıcıları ikna etmeye çalışan insanlar için kabul edilebilir olabilir ama sektör dışındaki insanlar için oldukça tuhaf görünebilir
Next bence zaten kendi kendini bozmuş bir örnek
VC döngüsünden geçen yerlerin sonu böyle oluyor
Artık kullanamıyorum; varsayılan tercihim Vite
Her zaman daha hafif çözümleri tercih ederim
Next.js'te "middleware" terimi yanlış anlamaya çok açık
Aslında uygulamaya ulaşmadan önce çalışan hafif bir edge function'dan ibaret (header kontrolü, routing, basit guard'lar vb.)
Edge runtime'da çalışır ve app server'dan ayrı bir ortamdır
Yazar da sanki edge ile server runtime'ı karıştırıyor
Ben de başta sınırları karıştırıyordum ve JavaScript merkezli olduğu için ayrım bulanıklaşıyor
Net bir zihinsel modele ihtiyaç olduğunu düşünüyorum
Next.js'in karmaşıklığını eleştirmek bana biraz, bir alet kutusunda çekiç dışında başka aletler de var diye şikâyet etmek gibi geliyor
Sorun, Next.js'in karmaşıklığının kendi eliyle yaratılmış olması
Middleware teriminin neredeyse tüm framework'lerde yerleşik ve net bir anlamı var
Normalde middleware, runtime içinde request'ten önce çağrılan fonksiyon zinciridir ve aynı process'te çalışacağı varsayılır
Next.js ise bunu edge'e yerleştirip yalnızca tek bir tane izin veriyor
Çoğu uygulamada edge özelliğine hiç gerek yok; gerektiğinde opt-in yapılması lazım
Alet kutusu benzetmesiyle söylersek, gerçekten gereken araçları eklemek gerekir
Next.js'te bu bağlamda "middleware" terimi kullanılmamalıydı
Bu sadece yanlış kullanım değil, aynı zamanda terim istismarı
Middleware'in web uygulama dünyasında eski ve yerleşik bir anlamı var; bambaşka bir şeyi kastediyorsanız bu adı kullanmamalıydınız
Ben Next.js app router kullanıyorum ve memnunum
Next.js ile frontend ve backend arasında gidip gelmek çok kolay olduğu için insanlar bu kısmın da soyutlandığını sanıyor olabilir
Ama gerçekte bu çok karmaşık bir sistem ve bu karmaşıklığı kendiniz üstlenmeniz gerekiyor
Karmaşıklığın yüksek olması her zaman yavaş ya da verimsiz olduğu anlamına gelmiyor
Frontend ile backend'in ayrıldığı sistemler yönetmesi daha kolay ama aynı zamanda daha uğraştırıcı
React biliyor olsanız bile Next.js tamamen yeniden öğrenilen bir şey gibi geliyor ve yaşamadan anlaşılmayan çok yönü var
Yine de belli bir alışkanlık kazandığınızda frontend ve backend arasında rahatça geçebildiğiniz çok kullanışlı bir sistem
Yorumuma çok kişi eksi oy verdi ama nedenini açıklamalarını isterim
Her zaman öğrenmeye açığım
Böyle tartışmalarda körü körüne olumsuzluk yerine gerçekten konuşabilsek keşke
Sonunda sağduyulu bir görüş gördüm diye düşündüm
Mesela Python'daki package/module kavramını Go'nun module kavramıyla düşünmeden karıştırırsanız, sonra da Go kötü diye şikâyet etmeye benzer
Her ne kullanıyorsanız onunla ilgili temel bir anlayışa sahip olmak gerekir
Next.js app router'a geçtikten sonra sanki express API'sini iyileştirme işi bootcamp mezunlarına bırakılmış gibi hissettirdi
Tüm server arayüzlerinin (servlet, rack, plug vb.) yıllar içinde biriktirdiği Russian-doll tarzı tasarımla uyumlu olması açısından express API yine de daha olgun bir yaklaşım
Berbat middleware API'sinin yanı sıra request parametrelerini kaldırıp yerine cookies()/headers() gibi global fonksiyonlar koymaları da tuhaf bir karardı
Muhtemelen altta yatan temel tasarım kısıtları var ama dışarıdan bakınca geçmişte öğrenilen bütün dersleri çöpe atıp aynı hataları yeniden yapıyorlarmış gibi görünüyor
Buna bir de lowest common denominator olan edge runtime desteği eklenince kısıtlar daha da sertleşti
Ben yeni projelerde hep farklı stack'ler denemeye çalışırım
express+react, angular, vue, next, nuxt, go, .net, node, php; frontend ve backend'in her tarafında çalıştım
Framework'lerin çoğunda artılar ve eksiler buluyorum, yeni şeyler öğrenmek de keyifli oluyor
Ama Next.js istisna; oldukça büyük bir uygulama yaparken baştan sona her şey ya tuhaf, ya yavaş, ya kullanışsız ya da akıl dışı tasarlanmış gibi geldi
Hâlâ bakımını yapıyorum ve nefret ettiğim tek "şey" bu
Ekosisteminin iyi olduğunu ve popüler olduğunu söylüyorlar ama benim gerçek deneyimim geri dönülmez derecede olumsuzdu
Tuhaf ama gerçek
Vercel'in posta adresini bilen var mı?
Bu issue gelecek yıl ilkokula başlama yaşına geliyor; şirkete "okul hayatında başarılar!" kartı göndermek istiyorum
https://github.com/vercel/next.js/issues/10084
Aşağıdaki Hacker News yorumundaki sözler tam isabet.
"Next.js, projelerin %99,9999’unda gerekmeyen devasa bir soyutlama katmanına sahip; gerçekten buna ihtiyaç duyulan az sayıdaki durumda ise bunun yerine daha alt seviye bileşenlerle özel bir çözüm oluşturmanın daha iyi olduğunu düşünüyorum"
Gereksiz yere aşırı karmaşık API’ler, kararsız ve eksik olmasına rağmen inatla production ready diye pazarlanmaları ve Vercel’e olan büyük bağımlılık yüzünden, Vercel olmadan ciddi şekilde işletmek de zor.