Kimlik doğrulamalı dashboard'lar için SSR vs SPA: Nuxt, önbellekleme, SEO

Aslında hangi problemi çözüyoruz?

İnsanlar “dashboard” dediğinde genellikle giriş yapılmış bir web uygulamasını kastediyor: tablolar, filtreler, grafikler, yönetici ekranları ve gün boyunca veri okuyan/yazayan formlar. Burada amaç Google'da bulunmak değil; erişimi olan kişiler için hızlı, güvenilir ve güvenli olmaktır.

SSR vs SPA seçimi karışık hale geliyor çünkü “hız” iki anlama gelebiliyor:

• Algılanan performans: sayfanın ne kadar çabuk hazır göründüğü ve tıklamalara nasıl yanıt verdiği.
• Gerçek performans: uygulamanın aslında ne kadar iş yaptığı (veri çekme, render, API gecikmesi, işlemlerin tamamlanma süresi).

Bir şey arka planda ağır işler yaparken hızlı görünebilir. Ya da ekran boş kaldığı için yavaş hissedilebilir, veri hızlı gelse bile.

Bir de birçok üründe bulunan iki parçayı ayırmak faydalı:

• Halka açık sayfalar: pazarlama sayfaları, dökümantasyon, fiyatlandırma, blog, açılış sayfaları.
• Özel uygulama: kullanıcıların işlerini yaptığı kimlik doğrulamalı dashboard.

Bu parçaların hedefleri farklıdır. Halka açık sayfalar arama görünürlüğünden, paylaşım önizlemelerinden ve agresif önbelleklemeden fayda sağlar. Dashboard ise oturum yönetimi, öngörülebilir veri yükleme ve giriş sonrası pürüzsüz uygulama içi gezinme ile daha çok ilgilidir.

Dolayısıyla gerçek soru “SSR mi yoksa SPA mı?” değil; kullanıcılarınıza, ekibinize ve altyapınıza hangi karışımın uyduğu. Yaygın bir desen, halka açık sayfalar için SSR veya SSG, giriş sonrası alan için daha SPA benzeri bir deneyimdir.

Tek bir en iyi cevap yok. Doğru yaklaşım ilk yükleme süresine ne kadar duyarlı olduğunuza, verinin ne sıklıkla değiştiğine, izinlerin ne kadar karmaşık olduğuna ve ne kadar operasyonel karmaşıklıkla çalışmak istediğinize bağlıdır.

SSR, SPA ve Nuxt basitçe

SSR (server-side rendering) sunucunun bir sayfanın ilk HTML'sini oluşturması demektir. Tarayıcı bunu hızlıca gösterir, sonra JavaScript sayfayı “uyandırır” ve etkileşimli hale gelir.

SPA (single-page app) tarayıcının önce uygulama kodunu indirdiği ve sonra ekranları tarayıcıda render ettiği yaklaşımdır. İlk yüklemeden sonra gezinme genellikle anlık hisseder çünkü istemci tarafında kalır.

Nuxt, her ikisini de destekleyen, Vue tabanlı bir çerçevedir. Yönlendirme, layout'lar, veri getirme kalıpları ve SSR, SSG ile bazı route'ların sunucu tarafında render edildiği veya diğerlerinin SPA gibi davrandığı hibrit modlar sağlar.

Kısaca hatırlama yolu:

• SSR: sunucu ilk görünümü render eder, tarayıcı sonra devralır.
• SPA: tarayıcı baştan itibaren render eder (sunucu çoğunlukla dosya ve API sunar).
• Nuxt: rota başına seçim yapabilirsiniz.

Kimlik doğrulamalı dashboard'lar için kilit an, kullanıcının giriş yapmadan önce ne olduğudur. Saf bir SPA'da tarayıcı önce uygulama kabuğunu yükler, sonra oturumu kontrol edip veriyi çeker. SSR ile sunucu, HTML göndermeden önce oturumu doğrulayabilir ve dashboard ya da yönlendirme döndürebilir.

Birçok ekip hibrite karar verir: pazarlama sayfası, fiyat ve döküm gibi halka açık sayfalar SSR veya SSG ile ön oluşturulur; biri giriş yaptığında dashboard verileri istemci tarafında çekilir. Bu, özel alanı duyarlı tutar ve her dashboard görünümünü sunucu render'ına zorlamaz.

Algılanan performans: neden SSR daha hızlı veya değilmiş gibi hissedebilir

İnsanlar bir dashboard'ın “hızlı” olduğunu söylediklerinde genellikle kullanılabilir hissi kastederler. Algılanan performans, kullanıcıların “Tamam, başlayabilirim” dedikleri ilk andır. Gerçek performans ise ölçebileceğiniz şeylerdir: ilk byte süresi, JavaScript indirme, API gecikmesi ve işlemlerin tamamlanma zamanı.

SSR ilk izlenimi iyileştirebilir çünkü sunucu hazır görüntülenebilir bir sayfa gönderebilir. Nuxt ile kullanıcılar genellikle JavaScript'in ekrandaki her şeyi baştan oluşturmasını beklemek yerine gerçek bir düzeni daha erken görürler.

Ama SSR yavaş veriyi düzeltmez. Eğer dashboard taze, kullanıcıya özel veri (görevler, grafikler, uyarılar) gerekiyorsa, sunucunun bunları almadan render yapamayacağı anlamına gelir. Yavaş bir API SSR'i de geciktirir. SPA'da ise kabuk göründükten sonra aynı yavaş yükleme durumlarını görürsünüz.

Algılanan performans çoğu zaman render modundan çok UI kararlarından gelir:

• Erken kararlı bir düzen gösterin (navigasyon, üstbilgi, sayfa başlığı).
• Spinner yerine tablolar ve kartlar için iskelet ekranları tercih edin.
• En önemli bloğu önce render edin (bugünün görevleri) ve daha derin analizleri erteleyin.
• Geçişleri öngörülebilir tutun, sayfalar zıplamasın.

Soğuk başlangıçlar ile tekrar ziyaretler de önemlidir. İlk ziyarette SSR “boş ekran” anını önleyebilir. Tekrarlayan ziyaretlerde SPA, varlıklar önbelleklendiği ve durum bellekte kaldığı için anında hissedilebilir.

Pratik örnek: bir satış dashboard'ı “Pipeline'ım”ı üç hizmetten yüklüyor. Bu hizmetler yavaşsa SSR ilk anlamlı paint'i geciktirebilir. Bir SPA ise yapıyı hemen gösterip veriyi geldikçe doldurabilir. Daha iyi soru: veri geç kaldığında bile kullanıcının görebileceği en erken faydalı görünüm nedir?

Önbellekleme: halka açık sayfalarda ve dashboardlarda neyi önbelleğe alabilirsiniz

Önbellekleme, halka açık site ile özel dashboard arasında ayrımı belirginleştirir.

Halka açık sayfalar çoğunlukla herkes için aynı olduğundan CDN, edge önbellekleme veya statik üretimle agresif şekilde önbelleğe alınabilir. SSR, sayfa kullanıcıya özel değilse ve HTML kısa süreli önbelleğe alınabiliyorsa iyi çalışır.

Dashboard'lar farklıdır. HTML veriden daha az önemlidir, veri kullanıcıya göre değişir. Hızlı dashboard'lar genellikle API yanıtlarını önbelleğe alıp, bellekte sonuçları yeniden kullanmak ve gereksiz yeniden getirmeyi önlemek üzerine kurulur.

Yaygın önbellek katmanları ve hangi durumlar için uygun oldukları:

• CDN ve edge önbellekleme: halka açık varlıklar ve HTML için mükemmel, kişiselleştirilmiş sayfalar için risklidir.
• Sunucu tarafı HTML önbellekleme: çıktı birçok ziyaretçi için aynıysa güvenlidir.
• API yanıt önbellekleme: sık tekrar edilen sorgular için faydalı, ama izinlere dikkat edilmelidir.
• Tarayıcı HTTP önbelleği: avatarlar, ikonlar ve versiyonlanmış dosyalar için iyi.
• Uygulama içi bellek önbelleği: gezinme hızlı hissetsin diye son sonuçları tutar.

Kullanıcı verisi içeren sayfaları render ederken SSR önbellekleme işi zorlaştırır. Sunucu "Merhaba, Sam" ve Sam'in müşterilerini render ediyorsa paylaşılan önbelleklemeden kaçınmalı veya çok sıkı önbellek başlıkları koymalısınız; aksi halde özel veri sızabilir.

SPA yine de sağlam bir istemci önbellekleme stratejisiyle hızlı olabilir: küçük bir kabuğu bir kez yükleyin, ortak API çağrılarını önbelleğe alın ve girişten sonra muhtemel sonraki ekranları önden getirin. Örneğin “bugünün pipeline'ı”nı bir kez alın, kullanıcı gezinirken bellekte tutun ve arka planda sessizce yenileyin.

Halka açık sayfalar ile uygulamayı iki ayrı önbellekleme problemi olarak ele alın.

SEO ihtiyaçları: halka açık sayfalar uygulamadan farklıdır

Bu tartışma, sitenizi iki ürün olarak ele alırsanız daha netleşir: bulunması gereken halka açık sayfalar ve giriş yapmış kullanıcılar için hızlı olması gereken özel uygulama.

Çoğu dashboard'un SEO değeri düşüktür. Arama motorları giriş yapamaz ve genellikle özel verinin indekslenmesini istemezsiniz. Dashboard için önemli olan giriş sonrası yükleme hızı, pürüzsüz gezinme ve güvenilir oturumlar; tarayıcı dostu HTML değildir.

Halka açık sayfalar farklıdır. İnsanların aradığı ve paylaştığı sayfalar bunlardır: pazarlama sayfaları, dökümantasyon, açılış sayfaları ve yasal içerikler.

Bu sayfalar için SSR veya SSG içeriği hemen HTML olarak sunar; bu indekslemeyi ve sohbet uygulamalarındaki paylaşım önizlemelerini iyileştirir. Temel unsurlar hâlâ gereklidir: net başlıklar, sayfa konusuna uygun başlıklar ve giriş duvarının ardında saklı olmayan içerik.

Yaygın bir Nuxt yaklaşımı hibrittir: halka açık sayfaları SSR veya SSG ile render edin, kimlik doğrulamalı alanı ise kullanıcı giriş yaptıktan sonra SPA benzeri davranacak şekilde ele alın.

AppMaster gibi bir platformla inşa ediyorsanız aynı ayrım geçerlidir: halka açık yüzeyi okunabilir ve stabil tutun; dashboard'u UX ve izinlere odaklayın, indekse kapatılacak sayfalar için SEO'yu aşırı optimize etmeyin.

Kimlik doğrulama ve oturumlar: SSR burada karmaşıklık ekler

Kimlik doğrulamalı bir dashboard için zorlu kısım UI'yı render etmek değil. Her istekte kullanıcının kim olduğunu ve neyi görmeye yetkili olduğunu belirlemektir.

Çoğu ekip cookie tabanlı oturumlar ile token tabanlı auth arasında karar verir.

Cookie oturumları HTTP-only cookie içinde bir oturum ID'si saklar. Sunucu bunu arayıp kullanıcıyı yükler. Bu SSR ile iyi uyumludur çünkü sunucu zaten isteği işliyor.

Token'lar (çoğunlukla JWT) her API çağrısıyla gönderilir. Bu SPA'lara uyabilir, ama token'ları localStorage'da saklamak XSS riskini artırır ve çıkış/yenileme davranışını karmaşıklaştırır.

SSR (Nuxt dahil) ile ekstra işler üstlenirsiniz çünkü sunucu render etmeden önce kimlik kararları vermelidir:

• Sunucu tarafında cookie'leri okuyup isteklerde oturumları doğrulamak.
• Çıkış yapılmış içerik yanıp sönmeden refresh veya yenileme mantığını yönetmek.
• Oturumu olmayan kullanıcıları güvenilir şekilde yönlendirmek ve döngülerden kaçınmak.
• Hydration sonrası sunucu ve istemci durumunu tutarlı tutmak.

Güvenlikle ilgili detaylar da daha görünür olur. Cookie'lere güveniyorsanız CSRF önem kazanır çünkü tarayıcılar cookieları otomatik gönderir. SameSite ayarları yardımcı olur, ama login akışınıza uygun olmalıdır. Durum değiştiren istekler için genellikle CSRF token'ları veya ek doğrulamalar hâlâ gerekir; özellikle SSR rotaları ve API rotaları yan yana bulunuyorsa.

SSR ile daha çabuk ortaya çıkan ortak kenar durumlar:

• Çoklu sekmede çıkış (bir sekme çıkış yapar, diğerinde önbelleklenmiş durum görünmeye devam eder).
• İstek ortasında oturumun süresinin dolması (sunucu bir şey render eder, sonra istemci 401 alır).
• Sayfa açıkken rol değişiklikleri.
• Geri butonunun tarayıcı önbelleğini kullanarak korumalı sayfaları geçici olarak göstermesi.

Bu yüzeyi azaltmak istiyorsanız, işi daha fazla API'lere itmek ve UI'yı istemci odaklı tutmak daha basit olabilir. Bazı ekipler ayrıca AppMaster gibi platformları tercih ediyor; çünkü yerleşik auth modülleri elle yazmanız gereken oturum boru hattını azaltır.

Barındırma ve işletme: SSR ile neler değişir

SSR yalnızca render stilini değiştirmez. Çalıştırdığınız şeyleri, izlediğiniz metrikleri ve ödediğiniz bedeli de değiştirir.

Bir SPA dashboard ile tipik olarak statik dosyalar sunarsınız ve API'leri çalıştırırsınız. SSR ile sunucu birçok istekte HTML renderlar. Bu ilk paint'i iyileştirebilir ama önbellekleme ve sınırlar koymazsanız daha yüksek ve öngörülemez sunucu yükü anlamına gelir.

Dağıtım farklı görünür

Yaygın kurulumlar:

• SSR uygulama sunucusu + API ve veritabanı
• Hibrit: statik halka açık sayfalar, gerektiğinde SSR, artı API'ler
• Tamamen statik pazarlama sitesi ve kimlik doğrulamalı dashboard için SPA

Statik dosyalar neredeyse her yerde düşük operasyonel yükle host edilebilir. Bir SSR sunucusu runtime, ölçekleme kuralları, health check'ler ve soğuk başlangıç/ani trafik artışlarına hazırlık gerektirir. Bu ek yükün maliyeti gerçektir.

İşletme sonrası işler (day-2) ağırlaşır

SSR hata gizlenebilecek daha fazla yer ekler: sadece sunucu render'ında olan, sadece tarayıcı hidratasyonunda çıkan veya sadece önbelleklenmiş bir cevap kullanıldığında görünen hatalar olabilir.

Temel bir işletme kontrol listesi şu öğeleri içermeli:

• Sunucu logları ile tarayıcı hatalarını ayrı tutun, her ikisini de kullanıcı/oturum ile ilişkilendirin.
• Route, oturum durumu ve render zamanını yakalayan tracing ekleyin.
• Sadece API trafiğini değil, zirve gezinme akışları sırasında sunucu CPU ve belleğini izleyin.
• Hangi şeylerin güvenle önbelleğe alınabileceğini ve veri değiştiğinde nasıl temizleneceğini belirleyin.

Ekip becerileri önemli. Eğer ekibiniz uygulama sunucuları çalıştırmaya ve sunucu ile istemci arasındaki hataları debug etmeye alışkınsa SSR buna değebilir. Değilse, halka açık birkaç SEO dostu sayfa ve SPA dashboard genelde daha kolay idare edilir.

AppMaster ile inşa ediyorsanız, backend, web uygulaması ve dağıtım hedefleri daha tutarlı paketlendiği için day-2 sürtüşmesi azalabilir.

Nasıl seçilir: basit bir karar akışı

Kimlik doğrulamalı bir ürün için SSR, SPA veya hibrit seçimi çoğunlukla sayfa türleri ve kullanıcı beklentileri ile ilgilidir.

Gerçek ekranlarınızı listeleyerek başlayın: pazarlama sayfaları, onboarding, ana dashboard, yönetici araçları ve ayarlar. Karışımı gördüğünüzde yön genellikle daha net olur.

Bu akışı kullanın ve küçük bir prototiple doğrulayın:

• Rotaları halka açık ve giriş gerektiren olarak ayırın.
• Hangi sayfaların indekslenmesi gerektiğini belirleyin (çoğunlukla sadece pazarlama ve dökümantasyon).
• Üç an için performans hedefleri koyun: ilk ziyaret, tekrar ziyaret, yavaş ağ.
• Kimlik doğrulama modelinizi ve yenileme davranışını yazın (cookie vs token, süre, yönlendirmeler).
• Bir mimari seçin, sonra temsilci bir akışı uçtan uca inşa edin (giriş, bir dashboard ekranı, bir halka açık sayfa).

Pratik bir kural

Eğer değerin %90'ı girişin arkasındaysa, SPA genelde daha basittir: daha az hareketli parça ve oturumlarla ilgili daha az sürpriz.

Eğer SEO dostu halka açık sayfalara ve düzgün bir ilk izlenime ihtiyacınız varsa, hibrit genelde dengedir: halka açık yüzeyi sunucuda render edin, dashboard'u ise client-driven tutun.

Örnek: pazarlama ve dökümantasyon ile birlikte özel bir yönetici alanı olan bir B2B aracı. Halka açık sayfaları SSR ile render edip, giriş sonrası SPA tarzı dashboard'a geçebilirsiniz. Hızlı bir prototip isterseniz AppMaster auth akışını ve veri modelini elle yazmadan test etmenize yardımcı olabilir.

Yaygın hatalar ve tuzaklardan kaçınma

Çoğu sorun framework ile ilgili değil; veri hızı, önbellekleme ve kimlik ile ilgilidir.

En büyük tuzak SSR'in yavaş API'leri gizleyeceğini beklemektir. Dashboard hâlâ birkaç yavaş çağrıya ihtiyaç duyuyorsa, sunucu render'ı bekletir; kullanıcı hâlâ bekler.

Bir diğer yaygın hata, kişiselleştirilmiş içeriği net bir önbellek hikâyesi olmadan sunucu tarafında render etmektir. Yanlış bir önbellek başlığı kullanıcıya özel HTML sızdırabilir veya önbelleği tamamen devre dışı bırakıp gecikme ve sunucu maliyeti ödemenize yol açabilir.

Diğer pratik tuzaklar:

• Tüm sayfaları SSR yapmak, oysa çoğu ekran özelse ve SEO gerektirmiyorsa gereksizdir.
• Erişim token'larını zararsız ayarlar gibi görüp localStorage'da saklamak ve XSS/çıkış planı olmadan bırakmak.
• Yönlendirme, yenileme mantığı ve oturum süresi davranışını UI bittikten sonra eklemek.
• Hem halka açık sayfalar hem de oturum açılmış uygulama için tek bir önbellek yaklaşımı kullanmak.
• Sadece temiz giriş senaryolarını test edip çoklu sekme, iptal edilmiş oturumlar ve uzun süreli boşta kalan sekmeleri atlamak.

Küçük bir örnek: Nuxt ile SSR edilmiş bir dashboard sayfası satış grafiğini gösteriyor. Eğer grafik verisi yavaş bir raporlama API'sinden geliyorsa, server-render edilmiş kabuk hâlâ takılı hissi verebilir. Genelde daha temiz olan, sadece halka açık sayfaları SSR edip kimlik doğrulamalı dashboard'u istemci tarafında render etmek ve net yükleme durumları ile akıllı API önbellekleme kullanmaktır.

Eğer dahili araçlar inşa ediyorsanız, AppMaster elle yazmanız gereken oturum ve yönlendirme mantığını azaltarak üretilebilir kod üretmenize yardımcı olabilir.

Karar vermeden önce hızlı kontrol listesi

Anonim ziyaretçiler ve giriş yapmış kullanıcılar için ürünün ne yapması gerektiğini yazın. Kötü kararlar ekipler dashboard'ı pazarlama sitesi gibi ele aldığında veya halka açık sayfaları sadece bir rota gibi gördüğünüzde çıkar.

Sağduyu kontrolleri:

• Arama sonuçlarında görünmesi ve dünya çapında hızlı hissedilmesi gereken halka açık sayfalarınız var mı (fiyatlandırma, dökümantasyon, açılış sayfaları)? Orada SSR veya ön-üretim planlayın.
• Dashboard yüksek derecede kişiselleştirilmiş ve sık güncelleniyor mu? Değer girişin arkasındaysa SEO önemsizleşir ve SPA genelde daha basittir.
• Ne güvenle önbelleğe alınabilir? HTML kullanıcı başına değişiyorsa tam sayfa önbellekleme risklidir. API ve statik varlıkları önbelleğe almak daha çok kazandırır.
• Oturum planınız yazılı mı (saklama, sona erme kuralları, yenileme davranışı, saatler sonra ne olur)?
• Ekip uzun vadede SSR çalıştırıp debug edebilir mi (sunucu logları, soğuk başlangıçlar, sadece prod'da görünen sunucu tarafı auth sorunları)?

Eğer “halka açık sayfalar önemli ama uygulama çoğunlukla özel” ise tipik çözüm: halka açık rotalar için SSR, giriş sonrası uygulama için SPA tarzı render.

Örnek senaryo ve sonraki adımlar

Küçük bir SaaS hayal edin: pazarlama sitesi (ana sayfa, özellikler, fiyatlandırma), halka açık dökümantasyon ve müşterilerin kullanıcıları, faturalandırma ve raporları yönettiği giriş gerektiren bir admin dashboard. Çoğu trafik halka açık sayfalara gelir, ama karmaşıklığın çoğu girişin arkasındadır.

Pratik cevap hibrittir. Nuxt ile halka açık sayfaları (SSR veya SSG) hızlı yüklenmesi, iyi önbelleklenmesi ve arama motorlarının anlaması için render edin. Dashboard'u bir uygulama olarak ele alın: girişten sonra veri çeken istemci tarafı bir kabuk, hızlı etkileşimlere odaklı ve her ekranı sunucu tarafında render etmeye zorlamayan bir yapı. API önbelleklemesine dayanarak performansı sağlayın.

Kimlik doğrulama iki dünyanın en farklı hissettirdiği yerdir. SPA dashboard'da tarayıcı genelde giriş gösterir, bir oturum oluşturur (çoğunlukla güvenli cookielar ile), rotaları istemci tarafında korur ve arka planda yeniler. SSR dashboard sayfalarında ise her istekte sunucu tarafında oturum doğrulaması yapar, HTML render etmeden önce yönlendirir ve kişiselleştirilmiş verinin sızmaması için önbelleğe sıkı davranır.

Sonraki adımlar:

1. Hangi sayfaların halka açık (ve SEO gerektiren) olduğunu, hangilerinin özel olduğunu listeleyin.
2. Temsilci bir akışı uçtan uca prototipleyin (giriş → dashboard'a iniş → bir rapor açma → oturumu yenileme → çıkış).
3. Oturum kurallarını erken belirleyin: cookie vs token, yenileme zamanlaması ve oturum ortasında sürenin dolması durumunda ne olacağı.
4. Gerçek verilerle algılanan hızı ölçün (soğuk yükleme, giriş sonrası gezinme, yavaş ağ davranışı).

Tam bir dashboard'u auth, veritabanı ve iş mantığı ile elle yazmadan oluşturmak isterseniz, AppMaster (appmaster.io) prototipleme ve üretime hazır uygulamalar göndermede pratik bir seçenek olabilir. Bu sayede public-vs-private ayrımını net tutarken altyapıyı hızlıca deneyebilirsiniz.