JekCMS ve Başsız CMS: Dürüst Bir Karar Çerçevesi

Önce açık kart: jekcms'i ben yazdım ve kendi yayın ağımdaki 14 siteyi onunla işletiyorum. Aşağıdaki her cümle o koltuktan yazıldı. Payını düşerek okuyun — ama karşılığında, kendi ürünümü hangi durumda önermeyeceğimi de açık açık söyleyeceğim. Çoğu CMS karşılaştırma yazısının yanaşmadığı şey bu.

Headless'ın gerçekten kazandığı yerler

İki senaryo var ve ikisi de gerçek.

Birincisi: çok kanallı içerik. Aynı yazı hem web sitenizde hem native mobil uygulamada hem mağaza içi ekranlarda hem de bir iş ortağının ürününde API üzerinden görünecekse, "içerik bir API'dir" yaklaşımı moda cümlesi değil, doğru mimaridir. Birleşik bir CMS HTML üretir; ondan bir de iOS uygulaması beslemesini istemek mümkün ama çirkindir. Headless tam olarak bunun için icat edildi ve bu işi iyi yapar.

İkincisi: gerçek bir frontend ekibi. Tüm işi bir React ya da Vue uygulaması olan — kendi sürüm takvimi, kendi testleri, kendi bileşen kütüphanesi olan — birkaç mühendis çalıştırıyorsanız, onları sunucuda render edilen PHP şablonlarına mahkûm etmek, parasını ödediğiniz yeteneği çöpe atmaktır. İçeriği veri kaynağı yapın, frontend'i onlara bırakın. O ölçekte iki sistem işletmenin operasyon maliyetini zaten ekip emer.

Kendinizi bu iki paragraftan birinde gördüyseniz okumayı bırakın ve gidip bir headless CMS seçin. Yazının kalanı sizin için değil; sizi hileli bir kontrol listesiyle kazanmaktansa burada dürüstçe kaybetmeyi tercih ederim.

Peki yayıncılığın geri kalanı neye benziyor?

Konferans konuşmalarının atladığı kısım şu: içerik operasyonlarının büyük çoğunluğu, açık web'e HTML sayfa yayınlayan bir-iki kişidir. Bir blog. Bir dokümantasyon sitesi. Haber bölümü olan bir şirket sitesi. Ortada iOS uygulaması yok. Frontend ekibi yok — siz varsınız, belki bir de mesai arkadaşınız.

Ben bu durumun uç örneğiyim: 14 canlı site, filo genelinde 5.500'ün üzerinde yazı, en büyük sitede 2.300'den fazla. Tek kişi. Hepsi Cloudflare arkasında paylaşımlı LiteSpeed hosting üzerinde dönüyor. İşte o kısıt — tek operatör, sıradan hosting — birleşik monolitin "eski mimari" olmaktan çıkıp rekabet avantajına dönüştüğü nokta.

Render katmanının ürünün parçası olması da işi kolaylaştırıyor. jekcms 13 bitmiş tema ve bir starter iskeletiyle gelir, TR ile EN'i tek kod tabanından servis eder; benim saatlerim frontend yeniden inşa etmeye değil yazıya gider. Headless yığında o katmanı sıfırdan siz inşa edersiniz — ve sonsuza dek siz bakarsınız.

Build hattını beklemeden yayınlamak

Headless artı statik üretim yığınında "yayınla" şu demektir: CMS'e kaydet, webhook'un tetiklenmesini um, build ya da revalidation'ı bekle, CDN'i bekle. İşler yolunda gittiğinde bu, bir-iki dakikalık gecikme ve sessizce bozulabilen fazladan bir sistemdir. Yolunda gitmediğinde — webhook ateşlenmedi, build alakasız bir commit yüzünden kırıldı — editörünüz bayat içeriğe bakar ve dört panelden hangisini açacağını bilemez.

jekcms'te yayınlamak, satırın veritabanına girmesi demektir; bir sonraki istek sayfayı render eder. Öndeki sayfa önbelleğinin TTL'i 300 saniyedir ve yayınla birlikte zaten temizlenir. Zamanlanmış yazılar cron bile istemez: zamanlayıcı normal trafiğin sırtında, yanıt ziyaretçiye teslim edildikten sonra koşar ve deterministiktir — yazı, damgasındaki saatte çıkar, "bir sonraki build ne zaman koşarsa o zaman" değil.

Günlük ritimde 14 sitede yayın yapıyorsanız bu fark akademik değildir. Yayınlamanın bir arka plan eylemi mi yoksa bir deployment olayı mı olduğunun farkıdır.

Hosting faturası

Filonun tamamı paylaşımlı hosting'de. Kubernetes kümesi değil, VPS bile değil — paylaşımlı LiteSpeed; kenar işini Cloudflare bedavaya yapıyor. Aynı filonun headless karşılığı şu demek: barındırılan CMS aboneliği (koltuk başı, alan başı, kayıt başı — fiyat eksenini siz seçin), artı site başına bir frontend host, artı ikisini yapıştıran tutkal. Rakip fiyat aktarmayacağım çünkü değişiyorlar; yapısal nokta değişmiyor: monolitin tek faturası olur ve o fatura ucuz cinstendir. jekcms tarafında ne ödeyeceğiniz de tek sayfada yazar.

"Paylaşımlı hosting bu yükü kaldırır mı?" sorusunun cevabı da mimaride saklı: sayfa önbelleği, sorgu önbelleği ve OPcache aynı monolitin içinde çalıştığı için isteklerin büyük kısmı veritabanına hiç inmeden dönüyor. İçerik sitesi trafiği öngörülebilirdir; öngörülemeyen trafiğe bağımsız ölçekleme gerekiyorsa zaten yazının ilk bölümündesiniz.

Gece 2'de kim tamir edecek?

Eklediğim her sistem, bizzat benim debug edeceğim bir sistemdir; başka kimse yok. Birleşik CMS'te arıza yüzeyi PHP, MySQL ve host'tan ibarettir. Bu kadar. Üçünü de tanıyorum.

Adil olayım — monolitin de keskin köşeleri var ve ben çoğuna çarptım. Kod dağıtımlarım GitHub Actions + rsync ile çıkıyor; Hostinger bir dönem IP'mi banlamaya başladı, çünkü paralel rsync işleri SSH auth'u dövüyordu. Çözüm SSH ControlMaster oldu: tüm transferler tek doğrulanmış soketi paylaşıyor. Deployment acısı her yerde var. Fark şu: birleşik kurulumda o acı yalnızca kod dağıtımını ilgilendirir. İçerik o hatta hiç uğramaz.

SEO tek kod tabanında yaşar — ya da ikiye bölünür

Headless tartışmalarında pek rastlamadığım bir argüman: teknik SEO da koddur ve o kodun bir yerde yaşaması gerekir. Kendi filomdan iki hata bu noktayı anlatmaya yeter.

Bir dönem, yazı bulunamadığında 404 durumu, header şablonu çıktıyı gönderdikten sonra set ediliyordu — başlıklar çoktan gitmişti, Google fiilen boş bir sayfaya 200 aldı. Ders kitabı düzeyinde bir soft 404; ve tarayıcı güvenini sessiz sessiz kemirir. Düzeltme, durumu (artı bir noindex başlığını) her türlü çıktıdan önceye taşımaktı. Ayrı bir vaka: jekcms.com'daki 87 dokümantasyon sayfasının tamamı, kendi URL'sine öz-referans vermeden aynı hreflang çiftini — /docs ile /tr/dokumantasyon — ilan ediyordu. Google'ın gözünde bu, kümenin tamamını geçersiz kılar. Çözüm: çifti gerçek istek yolundan üretmek.

İki hata da utandırıcıydı. İkisi de birer commit'le, tek kod tabanında kapandı ve tek hattan canlıya çıktı. Şimdi aynı hataları headless yığında oynatın: yanlış hreflang CMS'in locale metadata'sından mı geliyor, frontend'in head bileşeninden mi, yoksa yolları yeniden yazan CDN'den mi? Üç sistem, üç panel; herkes biletin kime ait olduğunu tartışırken tarayıcı sizi sessizce aşağı çeker. 14 sitenin sıralamasına tek başınıza cevap veriyorsanız, "düzeltme tek yerde" bir ayrıntı değildir. İşin ta kendisidir.

Kararı gerçekten veren dört soru

1. Bugün ikinci bir teslim yüzeyiniz var mı? "İleride uygulama yapabiliriz" değil. Bugün. Spekülatif kanallar, ekiplerin tek tüketicili bir API katmanına yıllarca bakmasıyla biter — o tek tüketici de birleşik CMS'in zaten bedavaya render edeceği web sitesidir.
2. Frontend ekibi mi var, frontend kişisi mi? Ekip, ayrı bir frontend uygulamasını yıllarca taşır. Kişi, iş değiştirene kadar taşır — ve headless'tan birleşiğe dönüşlerin en yaygın tetikleyicilerinden biri tam olarak o ayrılıştır.
3. Editoryal ne kadar hızlı canlıda olmalı? Birkaç dakikalık build gecikmesi sorun değilse headless de sorun değil. "Yayınla" kelimesi "şimdi canlı" anlamına gelmek zorundaysa — haber, düzeltme, hızlı deneme — veritabanından sayfaya giden yol açık ara kazanır.
4. Üçüncü yılda bunu kim işletecek? Mimarileri onlardan heyecan duyanlar seçer, geriye kim kaldıysa o bakar. Seçimi bakıcıya göre yapın.

Puanlamayı istediğiniz gibi yapın. Benim dürüst okumam: iki ya da daha fazla headless yönlü cevap varsa vicdan azabı duymadan headless'a gidin. Sıfır ya da bir ise, karmaşıklığı moda aksesuarı olarak satın alıyorsunuz demektir.

jekcms'in size vermeyeceği şeyler

Simetri bu bölümü zorunlu kılıyor. jekcms'in API yüzeyi içeriği içeri itmek için tasarlandı, dışarı sorgulamak için değil: webhook API'si publish, schedule, draft, update, delete, medya yükleme ve bulk-import uçlarını kabul eder; kimlik doğrulama Bearer API anahtarı ya da ham istek gövdesi üzerinde HMAC-SHA256 imzadır. Otomasyon için mükemmel — uçların tamamı dokümantasyonda — ama mobil uygulamanızın sorgulayacağı bir GraphQL içerik grafiği değildir. Ona ihtiyacınız varsa sizi yazının ilk bölümüne geri gönderiyorum.

Göç konusunda da dürüstlük gerek. Birinci sınıf içe aktarma yolu WordPress'i hedefler: admin'den yüklediğiniz SQL'den CSV'ye export, wp.org incelemesinde bekleyen resmi jekcms-migrator eklentisi ve göç sihirbazı. Kendi WordPress sitelerimden binlerce yazıyı bu yolla taşıdım. Contentful ya da Strapi için içe aktarıcı yok. Bir headless platformdan ayrılmak, içeriği onların API'sinden dışa aktarıp bulk-import ucuna kendi script'inizle beslemek demektir. Takvim sözü vermeden önce bu eforu bütçeleyin.

Bir arkadaşıma vereceğim kural

İçerik, birden fazla uygulamanın tükettiği bir ürün özelliğiyse headless'a gidin. İçerik ürünün kendisiyse ve web sitesi insanların onu okuduğu yerse, monolit çalıştırın; artırdığınız karmaşıklık bütçesini yazıya harcayın. Bu tavsiyeden pişman olmak için on dört fırsatım oldu. Henüz biri bile gerçekleşmedi.