Birkaç hizmetten canlı veri çeken statik bir site yayınladıysanız, Jamstack modelini zaten kullanmışsınızdır. Jamstack, ön ucunuzu önceden işleyip dinamik davranışları API çağrılarına taşıyan bir mimari yaklaşımdır; bu model Netlify tarafından 2015 civarında resmileştirilmiştir. Terim eskimiş görünse de, arkasındaki pratikler modern web geliştirmede hâlâ yaygındır.
Jamstack aslında ne anlama geliyor?
Jamstack, JavaScript, API'ler ve İşaretleme anlamına gelir.
- JavaScript tarayıcıda çalışır; veri çekme, kimlik doğrulama ve kullanıcı arayüzü güncellemeleri gibi dinamik işleri yürütür.
- API'ler monolitik arka ucun yerine geçer. Önceden işlemediğiniz veriyi HTTP üzerinden bir hizmetten alırsınız.
- İşaretleme, derleme aşamasında üretilmiş ve statik dosya olarak sunulan HTML'dir.
Uygulamada iki temel karar vardır:
- Sayfaları mümkün olduğunca derleme zamanında önceden üretmek.
- Ön ucu arka uçtan ayrıştırmak ve dinamik işleri API'lere taşımak.
Basit akış şöyle görünür:
Kaynak veri / CMS / API
↓
Derleme süreci
↓
Statik HTML + CSS + JS
↓
CDN
↓
Tarayıcı
↓
Gerektiğinde API çağrıları
Ayrıştırma nasıl çalışır?
Geleneksel bir yığında istek uygulama sunucusuna gider, sunucu veritabanını sorgular, HTML üretir ve yanıt döner. Ön uç ve arka uç aynı uygulamanın parçalarıdır.
Jamstack'te ön uç statik dosyalardan oluşur. Veritabanınızı doğrudan bilmez. Veri gerektiğinde bir API çağırır:
- Başsız CMS
- Ödeme servisi
- Arama sağlayıcısı
- Kendi arka ucunuz
- Üçüncü taraf SaaS API'leri
Bu yaklaşımda hizmetler arasındaki sözleşme paylaşılan kod değil, API'dir.
Pratik sonuçlar:
- Statik dosyalar CDN'den hızlı sunulur.
- Arama sağlayıcısını ödeme akışına dokunmadan değiştirebilirsiniz.
- Farklı ekipler farklı servislerden sorumlu olabilir.
- Risk, API sözleşmelerinin bozulmasıdır. Bir endpoint'in yanıt şekli değişirse ön uç kırılabilir.
Bu, ürün olarak API yaklaşımıyla aynı noktaya gelir. Ön uç bir hizmete yalnızca API üzerinden erişiyorsa, API artık uygulama detayı değildir; ürünün arayüzüdür. Bu da yazılımın neden başsız olmaya devam ettiğini ve API'nin neden ürün haline geldiğini açıklar.
Derleme zamanı verileri ile çalışma zamanı verileri
Jamstack uygularken en önemli karar şudur: Bu veri ne zaman alınmalı?
| Derleme zamanı verileri | Çalışma zamanı verileri | |
|---|---|---|
| Ne zaman çalışır? | Bir kez, derleme sırasında | Her sayfa yüklemesinde, tarayıcıda |
| Ne için uygundur? | Blog yazıları, dokümanlar, ürün katalogları, yavaş değişen içerikler | Sepetler, kullanıcı profilleri, fiyatlar, kişisel veya canlı veriler |
| Nasıl sunulur? | CDN'de statik HTML olarak | API çağıran JavaScript ile |
| Denge | Bir sonraki derlemeye kadar eski kalabilir | İlk yükleme daha yavaş olabilir ve canlı API gerekir |
Örnek karar matrisi:
Blog yazısı → Derleme zamanı
Dokümantasyon → Derleme zamanı
Ürün liste sayfası → Genelde derleme zamanı
Stok durumu → Çalışma zamanı
Sepet → Çalışma zamanı
Kullanıcı profili → Çalışma zamanı
Örneğin bir blog, yazıları derleme sırasında çekebilir. Böylece her okuyucu aynı hızlı statik sayfayı alır. Ancak alışveriş sepeti kullanıcıya özeldir; bu yüzden tarayıcıda API üzerinden alınmalıdır.
Basit bir istemci tarafı veri çekme örneği:
async function getCart() {
const response = await fetch("/api/cart", {
headers: {
"Accept": "application/json"
}
});
if (!response.ok) {
throw new Error("Sepet alınamadı");
}
return response.json();
}
Buradaki kritik nokta şudur: Statik katman derleme aracı tarafından çözülür. Dinamik katman ise tamamen API çağrılarından oluşur. Bu yüzden API'lerin doğru, hızlı ve iyi belgelenmiş olması gerekir.
Uygulamada araç zinciri
Tipik bir Jamstack projesi şu parçalardan oluşur:
-
Statik site oluşturucu veya meta framework
- Gatsby
- Hugo
- Jekyll
- Eleventy
- Next.js
-
Veri kaynakları
- Başsız CMS
- SaaS API'leri
- İç servisler
- Arama, ödeme veya kimlik doğrulama sağlayıcıları
-
Dağıtım katmanı
- CDN
- Statik hosting
- Gerektiğinde edge veya serverless function'lar
Örnek yapı:
/content veya CMS
↓
build
↓
/dist
↓
CDN
↓
Kullanıcı
Çalışma zamanı verisi gerektiğinde:
Tarayıcı
↓
API Gateway / Serverless Function / SaaS API
↓
Yanıt
Eğer bu MACH yaklaşımına benziyorsa, nedeni yakın akraba olmalarıdır. MACH; Microservices, API-first, Cloud-native ve Headless kelimelerinin kısaltmasıdır. Jamstack daha çok ön ucun nasıl üretildiği ve sunulduğuyla ilgilenir. MACH ise arka ucun bağımsız hizmetlerden nasıl oluşturulduğuna odaklanır.
Jamstack bugün nerede duruyor?
Jamstack terimi eski popülerliğinde değil. Netlify, 2023'te etiketi ana konumlandırmasından kaldırdı ve “composable web” etrafında yeniden markalaştı. Yıllık Jamstack Durumu anketi de topluluğun olgunlaşması nedeniyle 2024'te sona erdi.
Ancak uygulama ölmedi.
Bugün hâlâ şunlar yaygın:
- Önceden işlenmiş sayfalar
- CDN teslimatı
- API güdümlü arka uçlar
- Başsız CMS'ler
- Ayrıştırılmış servisler
Next.js gibi framework'ler sunucu tarafı işlemeyi tekrar yaygınlaştırarak çizgiyi bulanıklaştırdı. Bu yüzden “sadece statik” Jamstack yaklaşımı daha az görülüyor. Ama ana fikir kaldı: ön ucunuz bir istemcidir ve özellikleriniz API'lerden gelir.
Ayrıştırılmış bir yığında API kalitesi
Jamstack'te dinamik davranışlar API'lere taşındığı için API sözleşmesi kritik hale gelir. Ön uç şu sorulara güvenmek zorundadır:
- Endpoint mevcut mu?
- Yanıt şeması değişti mi?
- Hata formatı tutarlı mı?
- Auth davranışı net mi?
- Mock veri gerçek yanıta benziyor mu?
- CI sürecinde test ediliyor mu?
Bu noktada Apidog, mimarinin kendisini değil, API kalitesi katmanını yönetmeye yardımcı olur. Apidog bir CMS, hosting platformu veya Jamstack framework'ü değildir. API-first çalışırken sözleşme, mock, test ve dokümantasyon tarafında konumlanır.
Ayrıştırılmış bir yapı için pratik akış:
1. Önce API sözleşmesini tasarlayın
Ön uç ve arka uç ekipleri kod yazmadan önce yanıt şemasında anlaşmalıdır.
Örnek OpenAPI parçası:
paths:
/products:
get:
summary: Ürün listesini döner
responses:
"200":
description: Başarılı yanıt
content:
application/json:
schema:
type: array
items:
type: object
required:
- id
- name
- price
properties:
id:
type: string
name:
type: string
price:
type: number
Bu, API öncelikli geliştirmenin temelidir.
2. Arka uç hazır değilken mock kullanın
Arka uç tamamlanmadan ön uç geliştirmesini bekletmek yerine, API spesifikasyonundan mock sunucu oluşturabilirsiniz. Apidog, spesifikasyondan sahte sunucular kurarak ön uç ekibinin gerçekçi veriyle çalışmasına yardımcı olur.
Ön uç tarafında mock endpoint'e geçmek genellikle sadece base URL değiştirmek kadar basittir:
const API_BASE_URL = import.meta.env.VITE_API_BASE_URL;
export async function getProducts() {
const response = await fetch(`${API_BASE_URL}/products`);
return response.json();
}
Geliştirme ortamında mock, üretimde gerçek API kullanılabilir.
3. Sözleşmeyi CI içinde test edin
Ayrıştırılmış yapılarda bozuk API yanıtları statik ön ucu sessizce kırabilir. Bu yüzden API testleri pipeline içinde çalışmalıdır.
Genel hedef:
Pull Request
↓
API testleri
↓
Sözleşme doğrulama
↓
Build
↓
Deploy
Apidog CLI, API testlerini GUI olmadan CI sürecinde çalıştırmak için kullanılabilir. Böylece hatalı yanıtlar yayına çıkmadan önce yakalanır.
4. Dokümantasyonu güncel tutun
Jamstack projelerinde ön uç, arka uç ve içerik ekipleri çoğu zaman farklı araçlarla çalışır. API dokümantasyonu güncel değilse ekipler yanlış varsayımlarla geliştirme yapar.
Minimum dokümantasyon şunları içermelidir:
- Endpoint amacı
- Request parametreleri
- Response şeması
- Hata yanıtları
- Auth gereksinimleri
- Örnek istek ve yanıtlar
Apidog'un MCP desteği, bir yapay zeka aracısının veya IDE'nin API tanımlarıyla doğrudan çalışmasına olanak tanır.
Özetle: sözleşmeyi tasarlayın, mock oluşturun, test edin ve dokümantasyonu güncel tutun. Mimari size ait kalır.
Sıkça sorulan sorular
Jamstack statik bir site ile aynı mı?
Hayır. Statik site, dinamik veri içermeyen önceden oluşturulmuş HTML olabilir. Jamstack ise statik işaretlemeyi JavaScript ve API'lerle birleştirir. Böylece çoğu sayfa CDN'den statik dosya olarak sunulurken sepet, giriş ve canlı veri gibi özellikler API üzerinden çalışabilir.
Jamstack öldü mü?
Terim popülerliğini kaybetti ve Netlify 2023'te ana pazarlamasından kaldırdı. Ancak yaklaşım ölmedi. Önceden işleme, API güdümlü arka uçlar ve CDN teslimatı standart hale geldi. Bu yüzden birçok ekip artık buna Jamstack yerine modern web geliştirme diyor.
Jamstack geleneksel bir mimariden nasıl farklıdır?
Geleneksel yığın sayfaları veritabanına bağlı bir sunucuda işler. Jamstack ise sayfaları statik dosyalara önceden işler ve dinamik verileri API'ler üzerinden çeker. Ön uç arka uçtan ayrıldığı için kullanıcı arayüzünü yeniden yazmadan hizmetleri değiştirmek daha kolaydır.
Jamstack'teki API'ler ne yapar?
Önceden işlenmemiş her şeyi sağlarlar:
- İçerik
- Arama
- Ödemeler
- Kimlik doğrulama
- Kullanıcı verileri
- Canlı durum bilgileri
Ön uç bu verilere yalnızca API üzerinden ulaştığı için sözleşmeler kritik hale gelir. Ekiplerin paralel çalışabilmesi için bu API'leri önce tasarlayıp mock'layabilir, sonra yayınlamadan önce test edebilirsiniz.
Özetle
Jamstack, ayrıştırılmış bir web mimarisidir: işaretlemeyi önceden üretin, CDN'den sunun ve dinamik özellikleri API çağrıları olarak ele alın. İsim eski popülerliğini kaybetmiş olsa da model hâlâ yaygın.
Geliştirici açısından çıkarım net: Ön ucunuz sadece bir istemci olduğunda, API'leriniz ürünün arayüzü haline gelir. Bu yüzden API sözleşmesini önce tasarlamak, mock'lamak, CI içinde test etmek ve dokümantasyonu güncel tutmak gerekir.
Ayrıştırılmış ön ucunuzun bağımlı olduğu API'leri tasarlamak ve mock'lamak için Apidog'u indirin veya API'nizin neden artık ürün olduğunu daha fazla okuyun.
Top comments (0)