Headless CMS Nedir, Kimlere Uygun?

"Headless" kelimesi, CMS'in "başının", yani içeriği sayfaya döken tema katmanının ayrılması anlamına gelir. İçerik bir yerde yönetilir, sayfa başka bir yerde üretilir. Bu ayrım bazı projelerde büyük esneklik sağlarken bazılarında gereksiz karmaşıklık yaratır. Bu yazı farkı, bedelleri ve karar adımlarını anlatıyor.

Geleneksel CMS ile headless CMS farkı

Geleneksel bir CMS'te içerik, şablon ve sayfa üretimi aynı sistemde çalışır: editör içeriği girer, tema onu sayfaya dönüştürür. Headless kurguda CMS içeriği yapılandırılmış veri olarak saklar ve bir API ile verir; sayfayı ayrı bir uygulama üretir. WordPress'in REST API'si de bu kullanımı mümkün kılıyor: içeriğin tamamen ayrı uygulamalara taşınabileceği belirtiliyor 3. Yani aynı yazılım hem geleneksel hem headless kullanılabilir.

Bu tablo bir üstünlük sıralaması değil. Geleneksel CMS'in hazır önizlemesi, geniş eklenti ekosistemi ve tek parça yapısı birçok proje için doğru tercihtir. Platform seçimini daha geniş açıdan WordPress mi özel yazılım mı yazısında ele aldık.

İçerik modeli nedir?

Headless CMS'in kalbi içerik modelidir: hangi içerik türlerinin olacağı, her türün hangi alanlardan oluşacağı ve türlerin birbirine nasıl bağlanacağı. Örneğin bir kurumsal sitede "hizmet", "sektör", "ekip üyesi" ve "blog yazısı" ayrı içerik türleri olabilir; "hizmet" türünde başlık, kısa açıklama, uzun metin, görsel ve ilgili sektörlere bağlantı alanları bulunur.

Platformlar bu kavramı farklı adlarla anlatıyor ama mantık aynı:

• Strapi; birden çok kayıt tutan koleksiyon türlerini, tek kayıtlı türleri ve başka türlere eklenebilen yeniden kullanılabilir alan gruplarını (bileşenleri) ayırıyor 4.
• Sanity'de içerik modeli kodla yazılan şemalarla tanımlanıyor; belge türleri alanlardan oluşuyor, sürüm geçmişine sahip oluyor, taslak olarak tutulup yayımlanabiliyor ve editör formu şemadan otomatik üretiliyor 5.

İyi bir içerik modeli, içeriği görünüşüne göre değil anlamına göre böler. "Ana sayfa sol kutu metni" yerine "hizmet özeti" gibi bir alan, aynı içeriğin ana sayfada, hizmet sayfasında ve mobil uygulamada kullanılmasını sağlar. Kötü kurulmuş bir model ise editörü her sayfa için geliştiriciye muhtaç bırakır.

Next.js ile ilişkisi: önizleme ve yayın akışı

Headless CMS tek başına bir site değildir; içeriği sayfaya dönüştüren bir ön yüz gerekir. Next.js bu ön yüz için sık kullanılan çerçevelerden biridir ve dokümanında headless CMS ile çalışmanın iki kritik konusunu doğrudan ele alır.

Önizleme. Next.js'in Draft Mode özelliği, editörün taslak içeriği yayımlanmadan sitede görmesini sağlıyor. Draft Mode açıkken önbelleğe alınmış ya da önceden üretilmiş içerik atlanıyor ve veri doğrudan kaynaktan çekiliyor; diğer ziyaretçiler ise önbellekteki yayımlanmış sürümü görmeye devam ediyor 1. Doküman, önizleme adresinin CMS ile uygulama arasında paylaşılan gizli bir anahtarla korunmasını ve yönlendirmenin güvenli yapılmasını da adım adım anlatıyor 1.

Yayın. Sayfalar genellikle önceden üretilir ve önbellekten sunulur. Next.js'in artımlı statik yeniden üretim (ISR) yaklaşımı, tüm siteyi yeniden derlemeden statik içeriğin güncellenmesine imkân veriyor; belirli aralıklarla ya da talep üzerine, örneğin içerik yayımlandığında belirli bir yolun veya etiketin önbelleğini geçersiz kılarak çalışabiliyor 2. Vercel'in dokümanı da içerik odaklı platformlarda editörlerin CMS değişikliklerini yeniden dağıtım yapmadan yayımlayabildiği bir kurguyu örnek veriyor 6.

Bu iki akış kurulmadığında headless projelerin en sık şikâyeti ortaya çıkar: "Yazdığım şeyi göremiyorum" ya da "yayımladım ama sitede değişmedi". Önizleme ve yayın akışı, proje kapsamına baştan yazılması gereken iş kalemleridir. Next.js dokümanı ayrıca birden fazla sunucu örneği çalıştırıldığında talep üzerine geçersiz kılmanın yalnız çağrıyı alan örneği etkilediğini, bunun için paylaşılan bir önbellek gerektiğini not ediyor 2; kendi sunucunuzda barındıracaksanız bu ayrıntı önemlidir.

Avantajlar ve bedeller

Headless kurgunun getirdikleri:

• Tasarım ve performans kontrolü: Ön yüz tamamen size aittir; tema sınırı yoktur, sayfalar önceden üretilip CDN'den sunulabilir 6.
• Çok kanallı içerik: Aynı içerik web sitesi, mobil uygulama ve başka kanallarda kullanılabilir 3.
• Ayrık güvenlik yüzeyi: Yönetim paneli ile ziyaretçinin gördüğü site ayrı yerlerde durabilir.
• Yapılandırılmış içerik: İyi bir içerik modeliyle çok dilli siteler ve tekrar eden içerik blokları daha düzenli yönetilir.

Bedelleri:

• Geliştirici bağımlılığı: Yeni bir sayfa düzeni ya da yeni bir içerik türü çoğu zaman geliştirme gerektirir. Geleneksel CMS'teki "eklentiyi kur, bitti" yolu burada genellikle yoktur.
• Önizleme ve yayın kurulumu: Hazır gelmez; kurulur, test edilir ve bakımı yapılır 1.
• Maliyet yapısı: Başlangıçta ön yüz geliştirme ve içerik modeli tasarımı ayrı kalemlerdir. Üstüne CMS hizmetinin kullanıcı, kayıt ya da istek bazlı ücretlendirmesi ve barındırma maliyeti eklenebilir. Rakam yerine etkenlere bakın: editör sayısı, içerik hacmi, dil sayısı, trafik ve kendi sunucunuzda mı yoksa hizmet olarak mı kullanacağınız.
• Parça sayısı: CMS, ön yüz, barındırma, form servisi ve arama gibi bileşenler ayrı ayrı izlenir ve güncellenir. Bakım ortadan kalkmaz, dağılır; kalemleri web sitesi bakımı yazısında sıraladık.

Kimlere uygun, kimlere değil?

Çok dilli kurgularda içerik modelinin nasıl kurulduğu ayrı bir konu; ayrıntıları çok dilli web sitesi nasıl kurulur yazısında bulabilirsiniz.

Headless'a geçerken sık yapılan hatalar

Headless projelerde sorunlar genellikle teknolojiden değil, planlama eksikliğinden çıkar:

• Sayfa tasarımını içerik modeli sanmak. Her sayfa için ayrı, tek kullanımlık alanlar açmak modeli hızla dağıtır. Tekrar eden blokları ortak bileşen olarak tanımlamak, hem editörün işini hem bakımı kolaylaştırır 4.
• Editörü sürecin sonunda çağırmak. Alan adları, zorunlu alanlar ve form düzeni editörün günlük işine göre kurulmazsa panel kullanılmaz hâle gelir. Sanity gibi sistemlerde editör formu doğrudan şemadan üretildiği için şema kararları editör deneyimini belirler 5.
• Önizlemeyi sonraya bırakmak. Önizleme, proje bittikten sonra eklenmesi zor bir parçadır; içerik modeliyle birlikte tasarlanmalıdır 1.
• Önbellek stratejisini düşünmemek. İçerik yayımlandığında hangi sayfaların yenileneceği planlanmazsa ya eski içerik görünür ya da gereksiz yere tüm site yeniden üretilir 2.
• Mevcut içeriğin taşınmasını küçümsemek. Eski sistemdeki içerik çoğu zaman sayfa düzeniyle iç içe geçmiştir; yeni modele aktarmak için temizlik ve eşleme gerekir. Yeniden yönlendirmeler de bu işin parçasıdır.
• Arama, form ve üyelik gibi işleri unutmak. Geleneksel CMS'te eklentiyle çözülen bu işler headless kurguda ayrı servis ya da geliştirme gerektirir; kapsamda baştan yer almalıdır.

Karar adımları

1. İçerik envanteri çıkarın. Hangi içerik türleri var, kaç adet, kim güncelliyor, ne sıklıkla?
2. Kanalları belirleyin. İçerik yalnız web sitesinde mi kullanılacak, yoksa mobil uygulama ve başka kanallarda da mı?
3. Editör deneyimini tanımlayın. Önizleme, taslak, onay akışı ve zamanlanmış yayın gerekli mi 1?
4. İçerik modelini kâğıtta tasarlayın. Türleri, alanları ve ilişkileri görünüşe göre değil anlama göre çıkarın 4 5.
5. Ekip kapasitesini değerlendirin. Ön yüzde değişiklik gerektiğinde geliştirici erişiminiz var mı, bakım kimde olacak?
6. Maliyet yapısını karşılaştırın. Lisans ya da hizmet ücretinin hangi ölçüye bağlı olduğunu, barındırma ve geliştirme kalemlerini yan yana koyun.
7. Yayın akışını test edin. Bir içerik yayımlandığında sitenin ne zaman ve nasıl güncellendiğini bir deneme projesinde görün 2.
8. Çıkış planı yapın. İçeriğinizi standart bir biçimde dışa aktarabildiğinizden emin olun.

Headless kurguda içerik modelinden önizleme ve yayın akışına kadar neleri üstlendiğimizi headless ve Next.js hizmet sayfamızda bulabilirsiniz.