WebBlocks CMS neden bir Composer paketi?

Mevcut bir Laravel ürünü sayfalara, gezinmeye, medyaya, yerelleştirmeye ve editoryal iş akışına ihtiyaç duyduğunda ilk soru genellikle şöyle kurulur: CMS uygulamanın bir parçası mı, yoksa ayrı bir headless servis mi olmalı?

Bu soru yararlı bir ara seçeneği atlar. CMS, Laravel uygulamasının içinde çalışırken uygulamanın kendisi haline gelmeyebilir.

WebBlocks CMS, fklavyenet/webblocks-cms Composer paketi olarak dağıtılır. Bu tercih kurulum kolaylığından çok sahiplikle ilgilidir. Paket bir içerik sistemi sağlar; host uygulama Laravel ürünü olmaya devam eder.

Paketi kurmak proje kökünü CMS’ye teslim etmez. Host uygulama; başlangıç işlemleri, ortam ayarları, veritabanı bağlantısı, önbellek, kuyruklar, e-posta, zamanlanmış görevler, dağıtım, yedekler, public kökü ve ürüne özgü kodun sahibi olmaya devam eder.

Aynı zamanda kendi iş alanının sahibidir. Eğitim platformu kurslarını ve öğrencilerini, ticaret uygulaması siparişlerini ve müşterilerini korur. CMS bunların yanında pazarlama sayfaları veya dokümantasyon yayımlayabilir; ancak aynı süreçte çalışıyorlar diye host kavramlarını CMS kavramlarına dönüştürmemelidir.

Ad alanlarının önemli olmasının nedeni budur. WebBlocks /webadmin kullanır; host uygulamanın /admin yolunun CMS’ye ait olduğunu varsaymaz. Statik CMS dosyaları /cms altında bulunur. Rota adları, görünümler, yapılandırma anahtarları, tablolar ve yetkilendirme de benzer açıklıkta sahiplik gerektirir.

Laravel, paketin servis sağlayıcısını Composer üzerinden keşfeder. Paket rotalarını, ad alanlı görünümlerini, çevirilerini, migration işlemlerini, varsayılan yapılandırmasını, komutlarını, politikalarını ve statik dosyalarını kaydeder.

Sonuç, host uygulamanın app/ dizinine CMS controller ve modellerini kopyalamadan sayfalar, yerleşimler, bloklar, medya, yerelleştirme, revizyonlar, Shared Slots, gezinme, içerik API’leri ve operatör arayüzü gibi geniş bir özellik kümesidir.

Bu ayrım güncellemelerde önemlidir. Pakete ait kodun tek bir yetkili konumu vardır. Kaldırılmış bir CMS dosyası, proje kökünde eski bir özelleştirme olarak kalmak yerine paket değişimiyle ortadan kalkabilir. Sahiplikleri açık olduğu için host dosyalarıyla paket dosyaları farklı sürüm yaşam döngüleri izleyebilir.

Headless servis gerçek izolasyon sağlar. Bağımsız ölçeklenebilir, dağıtılabilir ve arızalanabilir; farklı teknoloji altyapılarındaki birden fazla ürün tarafından kullanılabilir. Bunlar gereksinimse HTTP sınırı doğru seçim olabilir.

Ancak entegrasyon işi de oluşturur. Kimlik doğrulama, yetkilendirme, önizleme, yerelleştirilmiş yönlendirme, medya erişimi, önbelleğin geçersiz kılınması, dağıtım koordinasyonu ve hata yönetimi ağ sınırını geçer. Uygulama verisine ihtiyaç duyan içerik genellikle başka bir API veya eşitleme katmanı gerektirir.

Paket farklı bir ödünleşim yapar. Host uygulamanın Laravel çalışma zamanını yeniden kullanır; aynı işlemlere, politikalara, yönlendirmeye ve dağıtıma katılabilir. Tek operasyonel sahibi olan tek bir Laravel ürünü için bu daha basit bir sınır olabilir.

Operasyonel ayrım kendi maliyetini hak etmelidir. Yararlı her iş akışı servisle ürün arasında özel bağlantı koduna ihtiyaç duyuyorsa ağ servisi kendiliğinden daha bağımsız sayılmaz.

Composer paketlemesinin gerçek maliyetleri vardır. CMS ve host aynı PHP sürecini, bağımlılık çözücüsünü, Laravel sürümünü ve veritabanı sunucusunu paylaşır. Sınırlar dikkatsiz tasarlanırsa rotalar, middleware, yapılandırma, tablolar, kimlik doğrulama varsayımları ve herkese açık yollar çakışabilir.

Şema sahipliği de disiplin gerektirir. Paket migration işlemleri CMS tabloları oluşturabilir; ancak yalnızca adı eşleştiği için mevcut bir host tablosunun sahibi olduğunu varsaymamalıdır. Kısmi kurulumlar yıkıcı tahminlerle değil, tespit ve açık onarım adımlarıyla ele alınmalıdır.

Kullanıcılar iyi bir örnektir. Ortak host, kimlik için tek bir users tablosu kullanabilir; CMS erişimi ise CMS rolleri ve site atamalarıyla temsil edilir. Host yöneticisi otomatik olarak CMS süper yöneticisi değildir; bunun tersi de geçerlidir. Aynı kimliği kullanmak iki yetkilendirme sistemini birleştirmemelidir.

Bunlar paket modeline karşı argüman değildir. Modeli gerçeğe dönüştürmek için yapılması gereken işlerdir.

Pratik bir test birçok mimari hatayı yakalar: Paketi ilgisiz bir Laravel ürününe kurduğunuzu düşünün.

Bu ürün yalnızca ilk host uygulamaya ait bir rota, dosya yolu, alan adı, başlangıç kaydı veya uygulama tanımı görür mü? CMS, host uygulamanın kendi yönetim adresini veya frontend derleme zincirini benimsemesini gerektirir mi? Güncelleme siteye ait içerik veya yapılandırmanın üzerine yazar mı?

Cevap evetse özellik büyük olasılıkla paket sınırını aşmıştır.

WebBlocks aynı kuralı çalıştırılabilir uygulamalara uygular. CMS çekirdeği genel kayıt ve yetki modelini sağlar; gerçek host uygulama tanımları ilgili kurulumun veritabanına veya deposuna aittir. Paket bir müşterinin dosya sistemi kurallarını bütün kurulumlara taşımamalıdır.

Composer ile kurulum, ancak kurulumdan sonra sahiplik açık kalırsa mimari bir vaade dönüşür:

• Laravel uygulaması ve operasyonlar host uygulamaya aittir;
• yeniden kullanılabilir CMS ürün kodu pakete aittir;
• site içeriği ve özelleştirmeler kuruluma aittir;
• host uygulamanın alan verileri onun alan verileri olarak kalır;
• kimlik doğrulama paylaşılabilir; yetkilendirme kendi kapsamını korur;
• içerik yayınlama yeteneği sessizce dağıtım yetkisine dönüşmez.

WebBlocks CMS’nin paket olmasının nedeni bu vaattir. Amaç her Laravel uygulamasını WebBlocks’a benzetmek değil, kendi kimliğini koruması gereken uygulamaya yapılandırılmış yayın yeteneği eklemektir.

Bağımsız operasyon, farklı teknoloji altyapılarında yeniden kullanım veya güvenlik izolasyonu ağ sınırını haklı çıkarıyorsa ayrı servis seçin. İçerikle ürün yakın entegrasyona ihtiyaç duyuyor ve tek Laravel çalışma zamanı dezavantaj yerine avantaj sağlıyorsa paket seçin.

Hangi sorumlulukları ayırmanız gerekiyor; ayırdığınızda hangileri daha zor hale geliyor?