JAMstack nedir? Sunucusuz hızın mantığı

Bir restoran düşünün: her sipariş geldiğinde aşçı markete gidiyor, malzemeyi alıyor, yemeği sıfırdan pişiriyor. Klasik web mimarisi böyle çalışır — her ziyaretçi için sayfa, veritabanından çekilen parçalarla yeniden üretilir. Bir de şunu düşünün: yemekler önceden pişmiş, vitrinde hazır; sipariş gelince sadece servis ediliyor. JAMstack budur.

"JAMstack nedir" sorusunun kısa cevabı bu benzetmede saklı: sayfaları ziyaret anında üretmek yerine önceden üretip, dünyanın her yerindeki sunuculardan hazır dosya olarak servis eden bir mimari yaklaşım. Uzun cevap ise birkaç kavramı açmayı gerektiriyor — çünkü isim, olduğundan daha karmaşık bir şey çağrıştırıyor.

Açılımı ne, nereden çıktı?

JAM üç harften geliyor: JavaScript, API, Markup. Terimi 2010'ların ortasında Netlify'ın kurucuları ortaya attı; bugün çoğunlukla "Jamstack" diye yazılıyor ve açılımından çok, temsil ettiği fikirle anılıyor.

Fikir şu: bir web sitesinin üç işi vardır. İçeriği göstermek (Markup — yani HTML), gerektiğinde etkileşim sağlamak (JavaScript) ve dinamik işler için dış servislerle konuşmak (API). Bu üçü, sayfayı her ziyarette üreten merkezi bir sunucuya muhtaç değildir. HTML önceden derlenir, JavaScript tarayıcıda çalışır, dinamik ihtiyaçlar API çağrılarıyla karşılanır.

Klasik mimariden farkı ne?

WordPress gibi geleneksel bir CMS'te akış şöyledir: ziyaretçi gelir → sunucu isteği alır → PHP çalışır → veritabanına gidilir → şablon doldurulur → HTML üretilir → ziyaretçiye gönderilir. Bu zincir her ziyarette, içerik değişmemiş olsa bile, baştan işler.

Jamstack'te aynı iş bir kez, build (derleme) anında yapılır. İçerik değiştiğinde bir derleme süreci çalışır, bütün sayfalar HTML dosyaları olarak üretilir ve bir CDN'e — dünyanın dört bir yanına dağılmış sunucu ağına — yüklenir. Ziyaretçi geldiğinde sunucunun yapacağı tek iş, hazır dosyayı uzatmaktır.

Fark, kaçırılması kolay ama sonuçları büyük bir yer değiştirmedir: iş, ziyaret anından yayın anına taşınır. Bin ziyaretçi de gelse, bir milyon da gelse, sayfa bir kez üretilmiştir.

Jamstack neden bu kadar hızlı?

Üç sebep üst üste biner:

• Hesap yok. Ziyaret anında çalışan uygulama kodu, bekleyen veritabanı sorgusu yok. Statik dosya servis etmek, bir sunucunun yapabileceği en ucuz iştir.
• Mesafe yok. Dosyalar CDN'de olduğu için İzmir'deki ziyaretçiye yakındaki bir noktadan, Berlin'dekine oradaki bir noktadan gider. Fiziksel mesafe kısalınca gecikme de kısalır.
• Kırılganlık yok. Trafik patlamasında çökecek bir uygulama sunucusu ortada yoktur. CDN'ler zaten milyonlarca isteği dağıtmak için kurulmuş altyapılardır.

Sonuç, milisaniyelerle ölçülen açılış süreleridir — ve bu hız bir optimizasyon değil, mimarinin doğal sonucudur.

"Sunucusuz" ne demek? Gerçekten sunucu yok mu?

Elbette var. "Sunucusuz" (serverless), sunucunun yokluğu değil, sizin yönetmediğiniz anlamına gelir. Güncellenecek işletim sistemi, yamalanacak PHP sürümü, gece çökme ihtimaline karşı izlenecek bir makine yoktur. Statik dosyaları barındıran altyapı da, form gönderimi gibi işleri karşılayan küçük fonksiyonlar da servis sağlayıcının sorumluluğundadır.

Bunun iki pratik sonucu var. Birincisi maliyet: statik barındırma, klasik hosting'e göre çok ucuzdur; küçük ve orta ölçekli siteler için çoğu zaman aylık birkaç dolara, hatta ücretsiz katmanlara sığar. İkincisi güvenlik: ziyaret anında çalışan kod olmayınca, saldırganın sömüreceği yüzey de dramatik biçimde küçülür. Hacklenecek admin paneli sayfayla aynı yerde durmaz.

İçerik nasıl yönetiliyor? Dinamik işler ne olacak?

En sık duyduğumuz itiraz: "Statik site dediğin el ile HTML yazmak değil mi? Biz içerik giriyoruz, sık güncelliyoruz." Hayır — içerik yönetimi ortadan kalkmaz, yer değiştirir.

İçerik bir headless CMS'te durur: yazı, ürün, duyuru ne varsa oradaki panelden girilir. Kaydettiğinizde derleme tetiklenir, site birkaç dakika içinde güncel hâliyle yeniden yayınlanır. Editör deneyimi klasik CMS'ten farksızdır; farklı olan, panelin ziyaretçiyle aynı sunucuda yaşamamasıdır.

Dinamik ihtiyaçlar da API'lerle çözülür:

• Formlar bir form servisine ya da küçük bir sunucu fonksiyonuna gönderilir.
• Arama önceden üretilmiş bir dizin üzerinden tarayıcıda ya da bir arama API'siyle çalışır.
• Ödeme zaten her mimaride dış servisle yapılır; Jamstack'te bu istisna değil, kuraldır.
• Kişiselleştirme gereken parçalar, sayfa açıldıktan sonra JavaScript ile çekilir.

Jamstack ile "statik site" aynı şey mi?

Yakın ama eşit değil. Statik site, çıktının biçimini anlatır: hazır HTML dosyaları. Jamstack ise bütün yaklaşımı anlatır: o dosyaların bir derleme sürecinden çıkması, içeriğin headless CMS'te durması, dinamik işlerin API'lerle çözülmesi. 2000'lerin el yazması HTML sayfaları da statikti; fark, bugünkü statik sitelerin arkasında tam teşekküllü bir içerik yönetimi ve otomatik yayın hattı olmasıdır.

Jamstack kimin için değil?

Dürüst olalım; bu mimarinin de sınırları var.

Saniyede değişen içerik. Canlı skor, borsa ekranı, sosyal ağ akışı gibi her kullanıcıya her an farklı görünen uygulamalar, önceden derlemenin mantığına ters düşer. Bunlar zaten "site" değil "uygulama"dır ve farklı mimari ister.

On binlerce sayfalı devasa siteler. Her içerik değişikliğinde koca sitenin yeniden derlenmesi, sayfa sayısı büyüdükçe dakikalara uzayabilir. Modern araçlar bunu artımlı derlemeyle (sadece değişen sayfayı üretme) büyük ölçüde çözdü, ama bu bir mühendislik konusudur; kendiliğinden olmaz.

Panelden her şeyi yapmak isteyen ekipler. Klasik CMS'te tema değiştirmek, eklenti kurmak paneldedir. Jamstack'te görsel ve yapısal değişiklik geliştirici işidir. İçerik ekibi özgürdür ama tasarım değişikliği kod ister. Bunu bir dezavantaj olarak görüp görmeyeceğiniz, sitenizin kaç elden geçtiğine bağlıdır.

Bir de şunu ekleyelim: beş sayfalık, yılda bir güncellenen bir tanıtım sitesi için WordPress da pekâlâ iş görür. Jamstack'in farkı, hız, güvenlik ve bakım maliyetinin sizin için gerçekten önemli olduğu yerde ortaya çıkar.

Peki neden herkes buna geçmiyor?

Çünkü geçiş bedava değil. Mevcut bir siteyi bu mimariye taşımak bir projedir; içerik modeli kurulur, tasarım yeniden inşa edilir, ekip yeni panele alışır. Ayrıca "Jamstack" tek bir ürün değil, bir yaklaşımdır — kalitesi, kuran ekibin kararlarına bağlıdır. Kötü kurulmuş bir Jamstack sitesi de yavaş olabilir; mimari sihirli değnek değil, doğru kurulduğunda avantajını kendiliğinden veren bir zemindir.

Vucod'un kurduğu siteler tam bu zeminde çalışıyor: statik build, headless CMS, CDN — ve üstüne kendi yönetim paneli. Böyle bir mimarinin sizin siteniz için anlamlı olup olmadığını merak ediyorsanız yazın, dürüstçe söyleyelim; her başvuruya 48 saat içinde dönüyoruz: vucod.com