Next.js ve Nuxt Uygulamaları İçin Doğru Hosting Mimarisi: SSR, SSG ve Edge Functions

Next.js veya Nuxt ile bir proje planlarken en zor kararlardan biri, sadece hangi UI bileşenlerini kullanacağınız değil; uygulamanın nasıl render edileceği ve hangi hosting mimarisi üzerinde çalışacağıdır. Proje planlama toplantılarında genellikle “SEO için SSR mi yapalım, yoksa performans için SSG mi?”, “Edge functions gerçekten gerekli mi?”, “Tek VPS yeter mi, yoksa ayrı API ve frontend mi kurmalıyız?” gibi sorular masaya gelir. Bu soruların cevabı doğrudan TTFB, Core Web Vitals, ölçeklenebilirlik ve maliyetlerinize yansır.

Bu yazıda DCHost olarak sahada sık gördüğümüz Next.js ve Nuxt mimarilerini; SSR (Server-Side Rendering), SSG (Static Site Generation) ve edge functions perspektifinden detaylı şekilde karşılaştıracağız. Hem küçük projeler hem de yüksek trafikli SaaS ve e‑ticaret uygulamaları için hangi yaklaşımın ne zaman mantıklı olduğunu, hangi durumda tek VPS’in yeterli, hangi durumda çoklu sunucu veya edge desteğinin şart olduğunu netleştireceğiz. Amacımız, elinizdeki iş yüküne bakarak “Bu projeyi DCHost üzerinde en mantıklı hosting mimarisiyle nasıl koştururum?” sorusuna kendi kendinize güvenle cevap verebileceğiniz bir çerçeve sunmak.

Next.js ve Nuxt’te Rendering Modellerini Netleştirmek

CSR, SSR, SSG, ISR ve Edge: Kısaca Haritayı Çizelim

Next.js ve Nuxt, React ve Vue ekosistemlerinde modern web geliştirmeyi kolaylaştırırken aslında birden fazla render modelini birlikte getiriyor:

• CSR (Client-Side Rendering): HTML iskeleti hafif gelir, veri tarayıcıda JavaScript ile çekilir. Klasik SPA yaklaşımı. SEO ve ilk yükleme süresi açısından her zaman ideal değil.
• SSR (Server-Side Rendering): Her istek geldiğinde sayfa sunucuda render edilir, tarayıcıya hazır HTML gönderilir; ardından hydrate olur. SEO ve ilk görünen içerik süresi (LCP) için güçlü.
• SSG (Static Site Generation): Build anında sayfalar statik HTML olarak üretilir ve genellikle CDN üzerinden servis edilir. Hızlı, ucuz ve ölçeklenebilir.
• ISR / Incremental Static Regeneration (Next.js): SSG + belirli aralıklarla arka planda yenileme. Hem hız hem güncellik dengesi.
• Edge Functions: Koda kullanıcıya en yakın edge lokasyonda çalıştırma imkânı. Özel header mantığı, AB/BA test, coğrafi yönlendirme, hafif SSR gibi işler için kullanılır.

Her modelin arkasında farklı bir hosting ihtiyacı ve mimari tasarım var. Sadece framework ayarlarını değil; sunucu tipini, CDN kullanımını, veri tabanı ve API yerleşimini birlikte düşünmek gerekiyor.

SSR Nedir, Next.js ve Nuxt’te Nasıl Çalışır?

SSR’de her HTTP isteğinde sunucu tarafında bir Node.js süreci sayfayı render eder. Next.js tarafında getServerSideProps, Nuxt tarafında server side rendering modu ve server middleware’leri bunun temelini oluşturur.

Bu mimaride:

• Her istek, CPU ve RAM tüketen bir render işlemi tetikler.
• Veri tabanı ve API istekleri genellikle her sayfa yüklemesinde yeniden çalışır.
• TTFB, PHP tabanlı klasik bir uygulamadan çok farklı değildir; hatta iyi optimize edilmemişse daha ağır bile olabilir.

Bu yüzden SSR kullanan Next.js/Nuxt projelerinde, Node.js süreçlerini barındıracağınız VPS veya dedicated sunucu seçimi kritik hale gelir. Bu konuyu daha geniş çerçevede ele aldığımız Node.js uygulamalarını nerede host etmeniz gerektiğini anlattığımız rehbere da göz atabilirsiniz.

SSG ve ISR: Jamstack Dünyasına Açılan Kapı

SSG’de sayfalar build aşamasında HTML’e dönüştürülür. Next.js’te getStaticProps + getStaticPaths, Nuxt’te statik generate modları ile bu sağlanır. Ortaya çıkan dosyalar:

• Klasik bir paylaşımlı hostingte,
• Bir VPS üzerindeki Nginx/Apache’de,
• Hatta bir object storage + CDN mimarisinde

tamamen statik olarak servis edilebilir. Bu yaklaşımın performans avantajlarını ve maliyet tarafını, Jamstack ve tamamen statik hosting mimarisi rehberimizde ayrıntılı anlattık.

ISR (Incremental Static Regeneration) ise SSG’ye küçük bir “zeka” ekler: Sayfa ilk seferinde statik üretilir, belirlediğiniz revalidate süresi dolduğunda arka planda yeniden oluşturulur. Böylece:

• Dinamik içeriklerinizi her istek için SSR ile yormazsınız.
• Yine de “içerik 12 saatten eski olmasın” gibi kuralları korursunuz.

Edge Functions: Kullanıcıya En Yakın Noktada Mantık Çalıştırmak

Edge functions, kodunuzu klasik tek bir veri merkezinde değil, çok sayıda edge lokasyonda çalıştırmanıza izin veren bir modeldir. Mantık şudur:

• Küçük ve hızlı fonksiyonlar, kullanıcıya coğrafi olarak en yakın noktada çalışır.
• Header manipülasyonu, AB/BA test, basit yetkilendirme, coğrafi yönlendirme, hafif SSR gibi işler burada yapılır.
• Kalın iş yükleri (veri tabanı, büyük rapor sorguları) hâlâ merkezi backend’de kalır.

Next.js ve Nuxt, runtime düzeyinde edge uyumlu handler’lar sunarak bu modele adapte olmanızı kolaylaştırıyor. Ancak edge functions, her zaman klasik Node.js hosting yerine geçmez; genellikle köprü bir katman olarak düşünmek daha doğru.

SSR, SSG ve Edge Functions’ı Teknik Olarak Karşılaştırmak

Performans Perspektifi

• SSG: En hızlı model. HTML zaten hazır, CDN üzerinden statik dosya gibi servis edilir. TTFB ve LCP metrikleri neredeyse sadece ağ gecikmesine bağlıdır.
• ISR: İlk istekten sonra SSG kadar hızlı; yenileme anında arka planda kısa bir yük oluşur ama kullanıcıyı nadiren etkiler.
• SSR: Her istekte render maliyeti olduğu için TTFB artar. CPU’ya ve veri tabanı gecikmesine çok duyarlıdır.
• Edge Functions: Hafif SSR veya HTML manipülasyonları için çok hızlıdır, çünkü coğrafi yakınlık ve hafif runtime avantajı vardır.

Özellikle Core Web Vitals odaklı çalışan projelerde hosting tarafında TTFB, LCP ve bağlantı gecikmesini nasıl iyileştirebileceğinizi Core Web Vitals’ı hosting tarafında iyileştirme rehberimizde detaylı anlattık. Next.js/Nuxt projeleri bu rehberden bire bir faydalanabilir.

Maliyet ve Kaynak Kullanımı

• SSG / ISR:
  • Çalışma zamanında neredeyse sıfır CPU tüketimi (sadece statik servis).
  • Yük arttıkça ek maliyet çoğunlukla sadece bant genişliği ve CDN tarafında oluşur.
  • Küçük ve orta ölçekli projelerde tek VPS + CDN ile yıllarca taş gibi çalışabilir.
• SSR:
  • Her istek CPU’ya bindiği için trafikle birlikte VPS veya dedicated sunucu maliyetiniz de artar.
  • Concurrency arttıkça Node.js worker sayısı, queue yapıları ve ölçekleme stratejileri devreye girer.
• Edge Functions:
  • Maliyet modeli genellikle isteğe göre veya çalışma süresine göre olur.
  • SSR yükünün bir kısmını edge’e alarak origin VPS’inizi daha küçük boyutlarda tutabilirsiniz.

Karmaşıklık ve Operasyonel Yük

• SSG: En basit operasyon. Build + deploy, gerisi mümkünse CDN. Sunucu taraflı hata senaryoları çok daha az.
• SSR: Node.js process yönetimi (PM2, systemd), Nginx reverse proxy, SSL, ölçekleme, loglama ve izleme gibi birçok katmanı birlikte yönetmeniz gerekir.
• Edge Functions: Mimariyi dağıtık hale getirir. İyi dokümante edilmezse hata ayıklama ve gözlemlenebilirlik zorlaşabilir.

Biz DCHost tarafında, SSR ağırlıklı Next.js/Nuxt projelerinde genellikle tek VPS → çoklu VPS → dedicated/colocation şeklinde büyüyen bir yol haritası öneriyoruz. Böylece gereğinden erken karmaşık küme yapıları kurmadan, projeyi trafikle birlikte doğal biçimde büyütmek mümkün oluyor.

Next.js ve Nuxt İçin Tipik Hosting Senaryoları

Senaryo 1: Tamamen Statik Kurumsal Site veya Blog (SSG)

Küçük ve orta ölçekli kurumsal siteler, içerik blogları, dökümantasyon siteleri için SSG çoğu zaman en mantıklı yaklaşımdır. Örneğin:

• Next.js ile tüm sayfaları getStaticProps ile build anında üretirsiniz.
• Oluşan out klasörünü paylaşımlı hosting veya bir VPS üzerinde Nginx ile servis edersiniz.
• CDN ekleyerek global ziyaretçilerinize daha düşük gecikme sunarsınız.

Benzetme yapacak olursak; bu mimariyi, veritabanı gerektirmeyen statik bir siteyi CDN + statik origin ile yayınladığımız klasik object storage tabanlı statik hosting rehberimize çok benzetebilirsiniz.

Bu senaryonun avantajları:

• Bakımı çok kolay, kırılma noktası az.
• CPU ihtiyacı minimal, düşük maliyetli.
• Core Web Vitals açısından çok güçlü başlangıç.

Dezavantajı ise içeriğin sık güncellendiği projelerde build sürelerinin uzaması ve deploy sıklığının artmasıdır. Bu durumda ISR veya SSR seçeneklerini düşünmek gerekir.

Senaryo 2: Haber Sitesi, Blog + Üyelik Alanı (SSR + SSG Hibrit)

Birçok projede hem statik içerikler hem de kişiye özel/oturum gerektiren sayfalar bulunur. Örneğin:

• Haber ve blog içerikleri SSG/ISR ile,
• Üyelik paneli, sepet, profil, dashboard gibi ekranlar SSR veya tamamen CSR ile

çalışabilir.

Bu senaryoda tipik mimari:

• Next.js/Nuxt uygulaması bir VPS üzerinde Node.js süreci olarak çalışır.
• Nginx reverse proxy TLS sonlandırma yapar, statik dosyaları kendisi servis eder.
• SSR/ISR sayfalar doğrudan Node sürecinden gelir.
• Veri tabanı (MySQL/PostgreSQL) aynı VPS’te veya ayrı bir veritabanı sunucusunda tutulur.

Bu yapı özellikle headless CMS + Next.js kombinasyonları için idealdir. Konuyu WordPress özelinde ele aldığımız headless WordPress + Next.js hosting mimarisi rehberimiz, Nuxt ve diğer headless senaryolara da bire bir uyarlanabilir.

Senaryo 3: Yüksek Trafikli SaaS veya E‑Ticaret (SSR Ağırlıklı + Önbellek + Ayrı Veritabanı)

Gerçek zamanlı fiyat, stok, kişiye özel öneriler, kullanıcı başına değişen dashboard’lar içeren SaaS ve e‑ticaret projelerinde SSR çoğu zaman kaçınılmazdır. Burada tipik büyüme adımları şöyle ilerler:

1. Başlangıç: Tek VPS üzerinde hem Next.js/Nuxt SSR hem de veri tabanı.
2. İlk ölçeklenme: Veri tabanını ayrı bir VPS’e veya dedicated sunucuya taşıma, uygulama VPS’ini sadece Node.js için kullanma.
3. İleri seviye: Birden fazla uygulama VPS’i, yük dengeleme (Nginx/HAProxy), Redis ile session & cache, belki okuma replikaları.

Bu tarz projeler için veri tabanı sunucusunu uygulama sunucusundan ne zaman ayırmanız gerektiğini anlattığımız rehber iyi bir yol gösterici olacaktır.

SSR ağırlıklı bu mimarilerde ayrıca:

• Nginx veya benzeri reverse proxy tarafında mikro önbellekleme kurarak anonim ziyaretçilerin ilk isteğini bile hızlandırmak,
• Kritik API istekleri için Redis/Memcached cache katmanı eklemek,
• Yoğun kampanya dönemleri için önceden load test yapmak

gibi adımlar performansı hayati derecede etkiler.

Senaryo 4: Edge Functions + Origin Backend

Global kullanıcı kitlesi olan, lokasyona göre değişen içerik sunan veya coğrafi odaklı A/B testleri yapan projelerde edge functions büyük fark yaratabilir. Basit bir senaryo:

• Kullanıcının coğrafi konumuna göre en yakın bölgeden edge function çalışır.
• Sayfa iskeleti veya basit HTML manipülasyonları edge tarafında yapılır.
• Ağır veri tabanı sorguları ve iş mantığı ise DCHost üzerinde çalışan merkezi API/VPS mimarinizde kalır.

Böylece:

• Origin sunucularınızın üzerindeki yük azalır.
• Coğrafi gecikme düşer, özellikle ilk bayt süresi (TTFB) iyileşir.

Edge functions, tamamen yeni bir hosting modeli değil; daha çok, mevcut DCHost altyapınızı tamamlayan bir hızlandırma katmanı gibi düşünülmeli.

DCHost Üzerinde Örnek Mimari Tasarımları

Küçük/Orta Ölçekli Nex.js/Nuxt Projesi İçin Basit Mimari

Yeni başlayan bir SaaS, içerik sitesi veya kurumsal proje için çoğu zaman aşağıdaki mimari yeterlidir:

• 1 adet VPS:
  • Node.js + Next.js/Nuxt uygulaması (PM2 veya systemd ile yönetilen 2–4 worker)
  • Nginx reverse proxy (TLS sonlandırma, statik dosya servisi, basit önbellek)
  • Küçük bir MySQL/PostgreSQL veritabanı (tek sunucu)
• Opsiyonel: Basit bir CDN ile statik dosyaların global hızlandırılması.

Böyle bir yapı ile:

• Binlerce günlük ziyaretçiyi rahatlıkla kaldırabilirsiniz.
• Hem SSR hem SSG/ISR sayfalar sorunsuz servis edilir.
• Operasyonel yük düşük, debug ve log yönetimi kolaydır.

Orta Ölçekten Sonraki Adım: Uygulama ve Veri Tabanını Ayırmak

Trafik ve veritabanı yükü arttığında ilk büyük sıçrama genellikle şu adımla gelir:

• 1 VPS: Sadece Next.js/Nuxt + Nginx (uygulama sunucusu)
• 1 VPS veya dedicated: Sadece veri tabanı (MySQL/PostgreSQL)
• Opsiyonel: 1 VPS: Redis/Memcached cache sunucusu

Bu ayrımı yaptığınız anda:

• Uygulama VPS’inizi CPU odaklı, veri tabanı VPS’inizi RAM/IOPS odaklı planlayabilirsiniz.
• Trafik arttıkça uygulama katmanını çoğaltmanız kolaylaşır.
• Veri tabanını replikasyon veya cluster yönünde geliştirmek için zemin hazırlamış olursunuz.

Yüksek Trafik İçin: Çoklu Uygulama VPS’i + Load Balancer

Trafiğin ciddi şekilde arttığı, anlık concurrency’nin yüzlerle ifade edildiği durumlarda tipik mimari şuna döner:

• 1 VPS veya küçük dedicated: Nginx/HAProxy load balancer
• 2+ VPS: Next.js/Nuxt uygulama sunucuları
• 1 strong VPS/dedicated: Ana veri tabanı sunucusu
• 1 VPS: Redis/Memcached, belki ayrı bir queue sistemi (BullMQ, Redis Queue vb.)

Bu tip mimarilerde kesintisiz güncelleme, mavi-yeşil dağıtım gibi yaklaşımlar önem kazanır. Zero‑downtime dağıtım konusunu Node.js projeleri özelinde GitHub Actions ile VPS’e otomatik deploy ve zero‑downtime yayın rehberimizde ayrıntılı anlattık; Next.js ve Nuxt projelerine aynı mantıkla uygulanabilir.

Deployment, CI/CD ve Gözlemlenebilirlik

Build Süreleri, CI/CD ve Ortam Ayrımı

SSR/SSG/ISR ve edge arasındaki teknik tercih kadar önemli olan bir konu da build ve dağıtım sürecidir. Özellikle SSG ve ISR kullandığınızda build süreleri uzayabilir ve:

• Geliştirme (dev), test (staging) ve canlı (prod) ortamlarını net ayırmak,
• Her ortama otomatik deploy yapan bir CI/CD pipeline kurmak,
• Build öncesi ve sonrası testleri otomatikleştirmek

kritik hale gelir. Geliştirme/test/canlı ortam ayrımını genel hosting perspektifiyle anlattığımız geliştirme, test ve canlı ortamlar için hosting mimarisi rehberi, Next.js/Nuxt projelerinizde de doğrudan uygulanabilir.

Loglama, İzleme ve Alarm

SSR ağırlıklı uygulamalarda Node.js süreçlerinin hatalarını görmek, response sürelerini izlemek ve CPU/RAM kullanımını takip etmek için iyi bir izleme ve alarm altyapısı kurmanız şarttır. Önerdiğimiz temel pratikler:

• Node.js loglarını (stdout/stderr) ayrı dosyalara veya merkezi log sistemine göndermek.
• Nginx access/error loglarını ayrı tutup, 4xx/5xx oranlarını takip etmek.
• VPS seviyesinde CPU, RAM, disk IO ve ağ trafiğini izleyen bir monitoring (Prometheus, Netdata vb.).

Bu sayede:

• SSR kuyruğunun tıkandığı, Node.js worker’larının yetersiz kaldığı anları erken yakalarsınız.
• Veri tabanı sorguları yavaşladığında, bunun SSR performansına etkisini görürsünüz.

Hangi Proje İçin Hangi Model? Karar Matrisi

Tek Sayfalık Landing, Basit Kurumsal Site

Öneri: %100 SSG, mümkünse CDN üzerinden statik servis.

• SSR ile uğraşmaya gerek yok.
• Veri tabanı zorunlu değilse, içerikleri dosya veya headless CMS ile build aşamasında çekmek yeterli.

İçerik Ağırlıklı Blog/Haber Sitesi

Öneri: SSG + ISR, sadece üyelik paneli veya yönetim ekranları için SSR/CSR.

• Anonim trafiğin büyük kısmı statik/ISR sayfalardan besleneceği için maliyet ve performans çok avantajlı.
• Yönetim paneli ayrı bir subdomain’de klasik SPA (CSR) bile olabilir.

SaaS Uygulaması, Dashboard, Analitik Araçlar

Öneri: SSR + CSR hibrit, kritik sayfalar için SSR, ağır rapor ekranları için CSR + API.

• Giriş sayfası/kampanya sayfaları SSG/ISR,
• Uygulama içi modüller SSR veya CSR + REST/GraphQL API kombinasyonu ile.

E‑Ticaret, Marketplace

Öneri: Katalog ve kategori sayfaları için SSG/ISR, ürün detay ve sepet/ödeme akışı için SSR.

• Katalog sayfalarını statik üretip CDN ile uçurmak,
• Sepet ve ödeme adımlarında SSR veya hızlı CSR ile kullanıcıya güven veren, hataya dayanıklı bir deneyim sunmak

burada iyi bir denge sağlar. WooCommerce tarafında anlattığımız yüksek trafikli siteler için önbellek, CDN ve veritabanı ölçeklendirme rehberindeki ilkeleri, Next.js/Nuxt tabanlı e‑ticaret projelerine de uyarlayabilirsiniz.

Global Hedefli Projeler

Öneri: SSG/ISR + CDN + gerekiyorsa edge functions + merkezi origin backend.

• Statik içerik ve anonim sayfaları dünyanın her yerine CDN’den verin.
• Yetkilendirme, kişiselleştirme ve ağır iş yüklerini DCHost üzerinde çalışan origin API’lerde tutun.
• Edge functions’ı hafif mantık ve coğrafi kişiselleştirme için kullanın.

Özet ve Yol Haritası

Next.js ve Nuxt size çok güçlü bir esneklik sunuyor; ama bu esnekliğin gerçek değeri, doğru hosting mimarisi ile birleştiğinde ortaya çıkıyor. SSR, SSG, ISR ve edge functions aslında birbirinin rakibi değil; her biri, belirli iş yükleri için optimize edilmiş farklı araçlar. Önemli olan elinizdeki projeye bakarak “Hangi sayfalarım gerçekten SSR’e ihtiyaç duyuyor, hangileri SSG/ISR ile rahatça çalışabilir, edge functions benim için gerçekten değer katıyor mu?” sorularına net cevap verebilmek.

DCHost üzerinde ister basit bir tek VPS, ister ayrı frontend/API/veri tabanı sunucularından oluşan daha kapsamlı bir mimari kurun; temel prensipler aynı kalıyor: önce hedefleri ve yükü anlamak, sonra mimariyi mümkün olduğunca sade ama büyümeye açık tasarlamak. Bu yazıdaki senaryoları kendi projenize uyarlarken, Node.js uygulamaları, statik hosting, veritabanı ayrıştırma, Core Web Vitals gibi konularda paylaştığımız diğer rehberlerden de yararlanmanız mimarinizi güçlendirecektir.

Eğer projeniz için en uygun Next.js/Nuxt hosting mimarisine karar veremiyorsanız, mevcut trafiğinizi, büyüme hedeflerinizi ve teknik gereksinimlerinizi birlikte değerlendirip DCHost altyapısı üzerinde sizin için net ve uygulanabilir bir yol haritası çıkartabiliriz. Tek VPS’ten çok sunuculu kümelere, SSR’den SSG/ISR ve edge kombinasyonlarına kadar tüm bu seçenekleri somut sayılar ve gerçekçi kapasite planlamasıyla konuşmak, ileride yaşayacağınız performans ve maliyet sürprizlerini en baştan engellemenin en sağlıklı yolu.