Bir web sitesini her ziyarette sunucuda yeniden üretmek yerine, önceden derleyip bir CDN'den dosya gibi sunmak mümkün. Jamstack mimarisinin özü bu. Sunucu tarafı sistemlere alışmış geliştiriciler için fikir başta tuhaf gelebilir, ama mantığı basit: statik HTML dosyası hiçbir veritabanı sorgusu beklemeden anında yüklenir, çünkü içerik zaten önceden hazırlanmıştır.
Bu yazıda Jamstack'in ne olduğunu, hangi araçlarla kurulduğunu ve hangi projelerde işe yaramadığını ele alıyorum. Statik site oluşturuculardan CDN dağıtımına, güvenlik farklarından gerçek kullanım senaryolarına kadar konuyu baştan sona işleyeceğim. Amaç, "Jamstack nedir" sorusunun ötesine geçip "ne zaman, nasıl kullanılır" sorusuna somut bir cevap vermek.
Jamstack Tam Olarak Nedir
Jamstack ismi JavaScript, API ve Markup kelimelerinin baş harflerinden geliyor, ama kısaltmadan çok "önce derle, sonra dağıt" felsefesini anlatıyor. Klasik bir PHP veya Node.js uygulamasında her istek sunucuda işlenir. Kullanıcı sayfayı her açtığında sunucu veritabanına gider, şablonu doldurur, yanıtı üretir; bu döngü her istekte tekrar eder.
Jamstack'te bu işlem bir kere, siteyi yayınlarken yapılır. Sonuç, statik HTML, CSS ve JavaScript dosyalarından oluşan bir klasördür. Bu klasör bir CDN'e yüklenir ve ziyaretçiye doğrudan sunulur; sunucu tarafı render süreci aradan çıkar.
Dinamik davranış gerektiğinde (form gönderimi, kullanıcı girişi, ödeme) bu işler istemci tarafından API çağrılarıyla yürütülür. Genelde üçüncü taraf servisler veya sunucusuz fonksiyonlar bu görevi üstlenir. Statik temel ile dinamik uçlar arasındaki bu ayrım, Jamstack'in en ayırt edici özelliği.
Statik Site Oluşturucular: Hangisini Seçmeli
Jamstack'in derleme aşamasını statik site oluşturucular (SSG) yürütür. En yaygın üç seçenek şöyle ayrışır:

- Next.js: React tabanlı, hem statik export hem sunucu tarafı render (SSR) destekler, ekosistemi geniş
- Astro: birden fazla framework'ü bir arada çalıştırır (React, Vue, Svelte), varsayılan olarak sıfır JS gönderir
- Hugo: Go ile yazılmış, binlerce sayfayı saniyeler içinde derler, blog ve dokümantasyon siteleri için uygun
Next.js projesinde statik export almak tek komutla yapılır:
npx next build && npx next export
Hugo'da yerel geliştirme sunucusunu ayağa kaldırmak şöyle çalışır:
hugo server -D
Astro'da yeni bir proje başlatmak için resmi CLI aracı kullanılır:
npm create astro@latest
Hangi aracı seçeceğiniz projenin doğasına bağlı. İçerik ağırlıklı bir blog için Hugo'nun derleme hızı fark yaratır; binlerce sayfalık bir site bile saniyeler içinde yeniden oluşur. Karmaşık, bileşen tabanlı bir arayüz için Next.js veya Astro daha esnek bir temel sunar, çünkü React veya Vue bileşenlerini doğrudan kullanabilirsiniz.
Küçük bir kişisel blog ile büyük bir kurumsal site arasındaki fark da bu seçimde belirleyici. Az sayıda sayfası olan bir proje neredeyse her araçta sorunsuz çalışır; on binlerce sayfalık bir katalogda ise derleme hızı ciddi bir kısıt hâline gelir.
API'ler ve Headless CMS Bağlantısı
Jamstack sitelerinde içerik genelde başsız (headless) bir CMS'ten çekilir. Contentful, Sanity veya Strapi gibi araçlar, içerik yönetim arayüzünü sunum katmanından ayırır. İçerik editörü tanıdık bir panelde yazı girer, site derlenirken bu içeriği API üzerinden çeker ve statik sayfalara gömer.

Bu ayrım, tasarımcının ön yüzü değiştirirken içerik modelini bozma riskini ortadan kaldırır. İçerik ekibi kendi işine odaklanır, geliştirici ekip kendi işine; ikisi arasındaki bağlantı sadece API sözleşmesidir. Bu iş bölümü büyük ekiplerde özellikle değerli.
Dinamik işlevsellik için üçüncü taraf API'ler devreye girer. Form gönderimleri Formspree gibi servislere, ödeme akışı Stripe'a, arama Algolia'ya yaptırılabilir. Bu yaklaşım, mikro hizmet mimarisinin daha spesifik bir biçimi olarak bazen "MACH mimarisi" adıyla da anılıyor. Her parça kendi uzmanlık alanında çalışan ayrı bir servis; bu modülerlik, sistemin tamamını değiştirmeden tek bir bileşeni değiştirmeyi mümkün kılar.
Performans Neden Bu Kadar Yüksek
Statik dosya sunmanın performans avantajı ölçülebilir. Sunucu tarafı render'da her istek veritabanı sorgusu, şablon işleme ve ağ gecikmesi biriktirirken, statik dosya CDN'in en yakın uç noktasından doğrudan iletilir. Core Web Vitals ölçütlerinde bu fark LCP (en büyük içerikli boyama) süresine doğrudan yansır.
CDN dağıtımı bu avantajı coğrafi olarak da büyütür. Cloudflare veya Netlify gibi sağlayıcılar, aynı statik dosyayı dünyanın farklı bölgelerindeki sunuculara kopyalar. İstanbul'dan erişen kullanıcı İstanbul'a en yakın node'dan yanıt alır, New York'tan erişen kullanıcı ise oradaki node'dan yanıt alır.
Sunucu tarafı render mimarisinde aynı coğrafi optimizasyonu yakalamak çok daha karmaşık bir altyapı gerektirir. Her bölgede sunucu kopyası çalıştırmak, veritabanı senkronizasyonunu yönetmek ve önbellek tutarlılığını sağlamak gerekir. Jamstack'te bu karmaşıklık büyük ölçüde CDN sağlayıcısının sorumluluğuna devredilir.
Sayfa hızı SEO'yu doğrudan etkilediği için bu performans kazancı arama sıralamasına da yansıyor. Google, sayfa deneyimi sinyallerini sıralama faktörü olarak resmen kullanıyor. Güncel rehberi web.dev üzerinden takip edebilirsiniz; ölçüm araçları ve eşik değerleri düzenli güncelleniyor.
Güvenlik Açısından Fark Ne
Sunucu tarafı render eden bir sitede saldırı yüzeyi geniş. Veritabanı bağlantısı, sunucu yazılımı, eklenti güvenlik açıkları ve SQL enjeksiyonu ihtimali bu mimarinin doğal riskleri. Jamstack sitesinde sunulan şey salt HTML, CSS ve JS dosyası olduğu için bu saldırı vektörlerinin çoğu ortadan kalkar.

Dinamik işlemler API'lere devredildiğinden, o API'lerin güvenliği ayrı bir servis sağlayıcının sorumluluğuna geçer. Bu, Jamstack'in güvenlik açığından tamamen bağışık olduğu anlamına gelmiyor. API anahtarlarının istemci tarafında ifşa olması, üçüncü taraf servislerdeki zafiyetler veya yanlış yapılandırılmış CORS ayarları hâlâ risk taşıyor.
Ama klasik WordPress sitesindeki eklenti güncellemesi kaynaklı güvenlik açığı sorunu Jamstack'te büyük ölçüde devre dışı kalıyor. Sunucuda çalışan bir yazılım olmadığı için o yazılımı güncel tutma derdi de ortadan kalkıyor. Bu, özellikle küçük ekiplerin veya tek kişilik projelerin bakım yükünü ciddi biçimde azaltıyor.
Hangi Projelerde İşe Yarar, Hangilerinde Yaramaz
Jamstack her proje için doğru seçim değil. İçerik ağırlıklı, sık güncellenmeyen siteler (kurumsal siteler, bloglar, dokümantasyon, portföy siteleri) bu mimariden doğrudan faydalanır. Bu tarz sitelerde içerik günde birkaç kez değişir, derleme süresi hiçbir zaman sorun olmaz.
E-ticaret siteleri de ürün sayfalarını statik oluşturup sepet ve ödeme akışını API'lere bağlayarak Jamstack'e uyarlanabilir. Next.js'in Incremental Static Regeneration (ISR) özelliği bu senaryoda ürün stoklarını periyodik olarak yeniden derler; böylece tüm siteyi baştan derlemeye gerek kalmaz. Bu hibrit yaklaşım statik performansı korurken içerik tazeliğini de sağlıyor.
Gerçek zamanlı, yoğun etkileşimli uygulamalar için geleneksel sunucu tarafı mimari veya tam SPA yaklaşımı genelde daha uygun kalıyor. Canlı borsa panosu, çok kullanıcılı düzenleme araçları veya karmaşık kontrol panelleri bu kategoriye giriyor; bu tür uygulamalarda veri o kadar sık değişiyor ki önceden derlemenin bir anlamı kalmıyor.
Derleme süresi de büyük sitelerde bir kısıt oluşturuyor. On binlerce sayfası olan bir haber sitesinde her içerik değişikliğinde tüm siteyi yeniden derlemek dakikalar sürebilir. Bu yüzden büyük ölçekte ISR veya kısmi hidrasyon gibi hibrit yaklaşımlara geçiliyor; saf statik yaklaşım her zaman en iyi çözüm olmuyor.
Karar verirken önce projenin içerik değişim sıklığına bakmak işe yarar. Günde birkaç kez güncellenen bir blog için Jamstack ideal bir seçim. Saniyede yüzlerce güncelleme alan bir uygulama için ise farklı bir mimari aramak daha doğru olur: mimari seçimi teknoloji trendini takip etmek değil, projenin gerçek ihtiyacını karşılamak için yapılmalı.
Henüz yorum yok.
Sohbete katıl. Yorumlar yayınlanmadan önce moderasyondan geçer.