- Hardcover ekibi, Next.js tabanlı yapının performans düşüşü, yüksek maliyet ve geliştirme hızındaki yavaşlama sorunları nedeniyle Ruby on Rails + Inertia.js'e göç etti
- SEO dostu SSR desteği, veritabanına doğrudan bağlanma ve React'i koruma gereksinimlerini karşılamak için Inertia.js seçildi
- Vercel ve Cloud Run'da yaşanan beklenmedik ücret artışları ile Next.js'in önbellekleme konusundaki belirsizliği, geçiş kararını kesinleştiren temel etken oldu
- Inertia.js, Rails backend'i ile React frontend'ini bağlamanın ideal yolu olarak öne çıktı; SSR ve önbellek yönetimi daha kolay hale geldi
- Geçişin ardından Google Pagespeed ve SEO puanları yükseldi; sitede geçirilen süre ve arama görünürlüğü arttı
Geçişin arka planı
- Başlangıçta, SEO ve SSR desteği sunan Next.js seçilerek GraphQL API tabanlı bir mimari kuruldu
- Verilerin çoğu tarayıcıdan istemci tarafında istenirken, statik veriler sunucuda önbelleğe alındı
- Zamanla önbellekleme eksikliği nedeniyle API istekleri arttı, performans düştü ve geliştirme ortamı yavaşladı
Next.js'te yaşanan sorunlar
- App Router'a geçildikten sonra da hız artışı sınırlı kaldı; Apollo POST istekleri önbelleğe alınmadığı için beklenen etki görülmedi
- Vercel fiyatlandırma politikası değişince aylık ücret $30'dan $354'e fırladı
- Cloud Run da başlangıçta ucuzdu, ancak $524'e kadar çıktı
- Next.js'in önbellek yapısını anlamak zordu; bu yüzden verimli yönetim mümkün olmadı
- Geliştirme hızı belirgin biçimde düştü ve yeni ekip üyelerini sisteme alıştırmak zorlaştı
Neden Rails + Inertia.js seçildi
- SSR'yi korurken veriyi doğrudan veritabanından almak istediler
- React'i kullanmaya devam etmek istediler; Remix, react-rails, react_on_rails de değerlendirildi ancak sonunda inertia-rails tercih edildi
- Inertia.js sayesinde frontend routing olmadan Rails routing'i kullanılabiliyor ve SSR de daha rahat uygulanabiliyor
- Controller'da
inertia: 'sayfa-adı' ile render işlemi yapılıyor, önbellek ise Rails.cache.fetch ile uygulanıyor
- React bileşenleri
usePage() ile props alıyor
SSR ve build yapısı
- SSR için
application.tsx içinde hydrateRoot / createRoot ayrımı yapılıyor
- Vite, bağımsız bir sunucu olarak çalıştırılıyor ve geliştirme sırasında hot reload desteği sağlıyor
- Docker ve Kamal ile Rails + Vite dağıtımı otomatikleştiriliyor, staging ve production ayrılıyor
- Dağıtım sırasında
make deploy komutu çalıştırılıyor; asset host tarafında CloudFlare ile önbellek optimizasyonu yapılıyor
Geçişin etkileri
- 18 Mart 2025'te göçün canlıya alınmasının ardından Google arama görünürlüğü arttı ve sayfa hızı iyileşti
- Total Blocking Time büyük ölçüde iyileşti ve Pagespeed puanları yükseldi
- Ziyaretçilerin ortalama sitede kalma süresi 3 dakikadan 6 dakikaya yükselme eğilimine girdi
- Trafik korunurken üyelik kayıtları istikrarlı biçimde sürdü
Gelecek görevler ve iyileştirme noktaları
- Ortak layout'ları yeniden kullanmak zor, ayrıca her sayfanın tamamen yeniden render edilmesi sorunu var
- SSR debug etmek zor ve ortam kurulumu karmaşık
- Inertia.js + Rails kombinasyonu için dokümantasyon yetersiz; sorunlar Discord topluluğu üzerinden çözüldü
- Suspense yerine Inertia yaklaşımına alışmak gerekiyor
- Şu anda Hasura kullanılmaya devam edildiği için Inertia'nın form, flash gibi bazı özellikleri henüz kullanılmıyor
Sonuç ve beklenti
- React + Rails'i doğal biçimde birleştiren yapı sayesinde geliştirme üretkenliği ve bakım kolaylığı arttı
- Inertia.js tercihiyle hız, SSR ve tip güvenliği aynı anda elde edildi
- Bundan sonra açık kaynak haline getirme ve katkı sağlayan geliştiriciler kazanma planlanıyor
2 yorum
Next.js'te
Linkkullanıldığında React Server Components kullanımı için URL'de?_rsc=1ip3igibi bir şey oluşturulup işlenmesi nedeniyle tartışma yaşanıyor. CDN kullanım ücretlerinin patladığına dair söylemler de var ve bu sorunun Next.js geliştirme ekibi tarafından da bilindiği söyleniyor; ancak hangi yöntemle ve ne zaman çözüleceği henüz belirsizmiş.Hacker News görüşleri
Sunucu tarafı render (SSR) hiçbir zaman ortadan kalkmadı; web ancak şimdi bunun neden varsayılan olduğunu yeniden hatırlıyor. İlk render ve SEO, işaretleme sunucudan geldiğinde hâlâ daha iyi oluyor. Rails + Turbo, HTMX, Phoenix LiveView, React Server Components gibi çeşitli framework'ler SSR'ı temel alıyor. Dashboard ve CRUD uygulamalarının çoğu istemci yönlendiricisine, global state'e ve 200kB hydration bundle'ına ihtiyaç duymuyor; sadece kısmi HTML değişimine ihtiyaç duyuyor
Asıl itici güç karmaşıklık maliyeti. İstemci JS'deki her satır, build araçları, npm denetim gürültüsü ve tedarik zinciri riski getiriyor. Bu yükü azaltmak hem performansı hem de güvenliği aynı anda iyileştiriyor. Elbette Figma veya Gmail gibi uygulamalar hâlâ ağır istemci mantığından fayda sağlıyor. Bu yüzden “varsayılan olarak HTML, JS sadece gereken yerde” deseni ortaya çıkıyor. Tam bir SPA yerine adacıklar düşünmek gerekiyor
Dolayısıyla sunucuya dönüş yaşanıyor, ancak bu 2004 PHP'sine duyulan bir nostalji değil. Mesele JavaScript'i doğru yerde kullanmak ve HTML'nin her zaman iyi yaptığı sıkıcı işlerin %90'ını ona bırakmak
NextJS'i birkaç projede kullandık ama şimdiden bunu aşamalı olarak bırakıyoruz. Bunun çeşitli nedenleri var, ancak başlıca etkenlerden bazıları şunlar
Kimlik doğrulama tarafı zorlu. next-auth bazı kısıtlamalara sahipti, bu yüzden iron-session kullanmaya başladık. Örneğin dinamik kimlik sağlayıcı alan adlarını kullanamıyorduk, bu nedenle tüm openid akışını bizim sahiplenmemiz gerekti. Yapılabilir bir şeydi ama olgun bir framework'te beklenmedik bir zaman kaybıydı
NextJS sunucusu bizim ana API gateway'imiz olmadığı için tüm istekleri proxy'lememiz gerekiyordu. Dokümantasyon net değildi ve istek zaman aşımı / maksimum başlık boyutu gibi rastgele sorunlar ekledi
Framework, buluta geçişi çok agresif biçimde teşvik ediyordu ve bu bizim hedeflerimizle çelişiyordu
Bakımcılar özellikle yardımcı değildi. Diğer araçları/framework'leri kusurlarına rağmen kullanıyoruz çünkü bakımcıları çok erişilebilir ve yardımsever oluyor (Chillicream/HotChocolate'a teşekkürler)
Geçen yıl Next.js'in pages router'ından app router'ına geçince SEO'nun iyileştiğini anlatan bir blog yazısı okuduğumu hatırlıyorum. Bu kez Vercel maliyetlerindeki artış nedeniyle Next'ten React+Inertia.js'e geçiyoruz. Aynı uygulamayı bulut sağlayıcısı yerine kendi VPS'imize dağıtmak sorunu çözecektir. Ancak neden bu kadar karmaşıklık istendiğini anlamıyorum. Bir kitap takip uygulamasının gerçekten GraphQL'e, ayrı bir frontend framework'üne ve karmaşık bir build sürecine ihtiyacı olup olmadığını ya da bunun en baştan HTML template'leriyle tek bir RoR uygulamasını bir VPS'e deploy ederek çözülebilip çözülemeyeceğini merak ediyorum
Web ve stack üzerine makale ya da tartışma gördüğümde kendime hep “aslında hangi problemi çözüyoruz?” diye soruyorum. Cevap her zaman “ekranda metin göstermek” oluyor
Özellikle DB de dahil olduğunda, insanlar JS full stack istediklerinde ne yaptıklarını merak ediyorum. ORM durumu oldukça parçalı ya da dümdüz SQL yazmanız gerekiyor. Sonra da hâlâ backend'e karar vermeniz lazım. express mi kullanacaksınız? Next.js iyi biliniyor ama şüpheli bir ajandası var. Remix, Astro, TanStack vb. Her zaman ne kullanacağınızı yeniden ayarlayıp yeniden değerlendirmek zorunda olduğunuz için kafa karıştırıcı
Kişisel projelerde sık sık Ruby on Rails'e dönüyorum. Her zaman keyifli. Öte yandan, kullanılabilir Rails geliştiricisi sayısı çok az olduğu için (JS ile kıyaslandığında) profesyonel projeler için uygun değil. Backend için JS'yi ve çoğu zaman Java'yı seçmek sorumsuzluk sayılmaz
Benzer duygulara sahip başka biri var mı merak ediyorum
Frontend ve backend geliştiricileri uzun zamandır birbirleriyle iyi iletişim kuramıyor
Tarihsel olarak, bir backend geliştiricisi olarak Html/JS/CSS'den nefret ediyordum. Swing/Awt, WinForms, Android UX vb. ile kıyaslandığında anlamlı biçimde farklı bir paradigma. Bu bile tek başına beni hayal kırıklığına uğratıyor ve backend'de kalmama neden oluyordu. Frontend öğrenmek için bu üçünü öğrenmek gerekiyordu. Ancak şimdi alışmaya başlıyorum
Ama frontend geliştiricilerinin de “bir başka dil” öğrenmesi gerekiyordu. Birçok dilin nvm ile karşılaştırıldığında farklı/sinir bozucu build sistemleri var. Ve dil değiştiren herkesin bildiği gibi, yeni framework'ler, paradigmalar vb. de öğrenmeleri gerekti
Bunun yerine bazıları JavaScript'i backend'e itebileceklerini fark etti. Bunun birçok dezavantajı vardı ama “işi bitiren” insanlar için, özellikle de “daha fazla sunucu ekle” ve “VC fonu bedava! Altyapıda yak gitsin!” dünyasında, bunlar endişe edilecek dezavantajlar değildi
Ancak frontend geliştiricileri, artık “full stack geliştiriciler” ama gerçekte “her şeyi JavaScript ile yapan geliştiriciler”, görünür biçimde üretmeye devam etti. Bu durum bugün LinkedIn iş ilanlarına yansımış durumda; Next.JS/Node.JS/diğer rolleri istiyorlar. Her şeye hükmeden tek bir dil
Bunlar sadece birkaç düşünce ama insanların neden Next.JS'i seçtiğiyle güçlü biçimde ilişkili olduğunu düşünüyorum
Teknik tarafta konuşamam (yalnızca Next.js'e aşinayım, Rails'e değil; bu yüzden bu yazının yazarın Rails konusundaki rahatlığını mı yoksa teknik olarak daha uygun bir mimariyi mi yansıttığı belirsiz). Ancak birden fazla yazılım mühendisinin bulunduğu bir şirketin aylık 1.000 doların altındaki altyapı maliyetini dert etmesini garip buluyorum. Hosting maliyetlerini dert etmek akıllıca değil
Rails, frontend framework'leriyle birlikte çalışabilirliğe yönelik gerçek bir birinci sınıf desteğe odaklansaydı, şimdiye kadar çok daha büyük olurdu. Hotwire için çok emek harcadılar ama ben React kullanmak istiyorum ve başkaları da muhtemelen alışkın oldukları şeyi kullanmak isteyecektir
Next.js ile SSR arasında neden bir tartışma var merak ediyorum. Next.js hibrit bir yapı ve bunu oldukça iyi yapıyor. Diğer SPA framework'lerinin aksine, Next.js hızlı ilk yükleme için önceden render edilmiş HTML çıktısı üretiyor; verimli JS chunk'ları, link üzerine gelince ya da sayfa render edildikten sonra tüm n+1 bağlantıları preload etme gibi ayar anahtarları sunuyor ve breakpoint'e göre verimli görsel (ön) yükleme sağlıyor (bu, saf SSR çözümlerine kıyasla genelde aşil topuğudur)
Biraz Rails yazdım ama insanların neden bu kadar heyecanlandığını pek anlayamıyorum. Gayet iyiydi ama özel bir yanını görmedim