Tek altyapı, birçok site: çok dilli bir CMS'te içerik modeli

01Ortak altyapı, farklı yayın alanları

Problem kâğıt üzerinde basit görünüyor: farklı merkezlerin içerik üretimini, yetkilerini ve yayın akışını tek bir sistemde toplamak. Zorluk, bunu yaparken her sitenin kendi bağlamını koruması gerekmesinde. Bir merkezin editörü yalnızca kendi sitesini, kendi dillerini ve kendi onay sürecini görmeli; ziyaretçi de yalnızca o sitenin içeriğiyle karşılaşmalı. Ortak altyapı ile ayrı yayın alanı arasındaki bu denge, bütün katmanlara yayılan asıl tasarım sorusu.

Bu iki ihtiyaç ilk bakışta birbirine ters düşüyor. Ortaklık; bakımın, güncellemelerin ve yeni yeteneklerin tek seferde bütün sitelere ulaşması demek. Ayrışma ise her merkezin kendi dilinde, kendi editörleriyle ve kendi takvimine göre yayın yapabilmesi. Bu tür sistemlerde benim ilk yaptığım şey, hangi kararın herkes için ortak, hangisinin siteye özel olduğunu açıkça ayırmaya çalışmak. Bu ayrım net değilse, zamanla ya her site için ayrı bir istisna yazılıyor ya da ortak yapı bir sitenin ihtiyacını diğerine dayatıyor.

02Üç katman, bir veri

Sistem üç parçadan oluşuyor: kamuya açık Next.js web arayüzü, NestJS ile yazılmış API ve React ile geliştirilen yönetim uygulaması. Üçü de PostgreSQL üzerinde buluşuyor; Drizzle ORM ve Docker da yığının parçası. Bu ayrım, editör deneyimini ve ziyaretçi deneyimini birbirinden bağımsız geliştirmeyi mümkün kılıyor. Ama aynı içerik modeline dayandıkları için ikisi de aynı kurallara uymak zorunda.

web    Next.js     → ziyaretçinin gördüğü sayfa
admin  React       → editörün günlük işi
api    NestJS      → site bağlamı, dil, onay
db     PostgreSQL  (Drizzle ORM)

Katmanların öncelikleri de farklı. Ziyaretçinin gördüğü web tarafında öncelik, sayfanın hızlı açılması, doğru dilde gelmesi ve arama motorları için anlaşılır olması. Yönetim tarafında öncelik, editörün formlarla, taslaklarla ve onay adımlarıyla rahat çalışabilmesi. API ise bu iki dünyanın arasında bir hakem gibi duruyor: bir isteğin hangi siteye, hangi dile ve hangi yetkiye ait olduğuna o karar veriyor. Benim için bu yapının en değerli yanı, kuralların tek bir yerde yaşaması; arayüzler o kuralları yeniden yazmak yerine sonuçlarını gösteriyor.

Docker gibi bir araç, bu katmanların farklı ortamlarda aynı biçimde ayağa kalkmasını kolaylaştırıyor. Çok parçalı bir sistemde bu tutarlılık, geliştirme ortamı ile canlı ortam arasındaki farkları azaltmaya yardımcı oluyor.

03İçerik modeli yalnızca bir şema değil

Çok dillilik, site bağlamı ve içerik onay akışları bu ürünün temel parçaları. Bir içeriğin hangi siteye ait olduğu, hangi dillerde bulunduğu ve yayına çıkmadan önce hangi adımlardan geçtiği; veritabanındaki tablolar kadar yönetim panelindeki ekranları ve web arayüzündeki sayfaları da şekillendiriyor.

Bu yüzden içerik modelini konuşurken yalnızca alanları ve ilişkileri düşünmüyorum. Bir alan zorunlu mu, çevrilebilir mi, siteler arasında paylaşılabilir mi; bu soruların her biri editörün ekranında bir davranışa, ziyaretçinin sayfasında da bir sonuca dönüşüyor. Modelde belirsiz bırakılan bir nokta, genellikle arayüzde bir kafa karışıklığı olarak geri geliyor. Çok siteli bir yapıda site bağlamını sonradan eklenen bir filtre olarak değil, her isteğin baştan taşıdığı temel bir bilgi olarak görmeyi daha güvenli buluyorum.

İçerik modeli, editörün gününü ve ziyaretçinin sayfasını birlikte tasarlar.

04Dil ve onay: iki ayrı eksen

Çok dilli sistemlerde sık düşülen tuzaklardan biri, çeviriyi içeriğin basit bir kopyası gibi düşünmek. Oysa aynı içeriğin farklı dillerdeki sürümleri farklı zamanlarda hazırlanabilir, farklı kişilerin elinden geçebilir ve farklı aşamalarda bulunabilir. Bu tür yapılarda dili ve yayın durumunu birbirinden bağımsız iki eksen olarak düşünmek bana daha sağlıklı geliyor. Böylece bir dildeki sürümün yayında, diğerinin hâlâ hazırlıkta olması bir istisna değil, modelin doğal bir hâli oluyor.

Onay akışı da aynı mantıkla ele alınmalı. Bir içeriğin taslak, incelemede ya da yayında olması yalnızca bir durum bilgisi değil; kimin neyi görebileceğini ve kimin neyi değiştirebileceğini de belirliyor. Yetki ile iş akışı birbirine bu kadar bağlıyken, ikisini ayrı ayrı tasarlamak yerine aynı modelin parçaları olarak düşünmek tutarlılığı korumayı kolaylaştırıyor.

05Bu projede benim yerim

YEE CMS bir Unitic projesi ve ekip işi. Benim katkım full-stack geliştirme ve entegrasyon tarafında: arayüz, servis, içerik yönetimi akışları ve katmanların birlikte çalışması. Entegrasyon işi bana en çok, bir katmanda verilen kararın diğer katmanlarda nasıl karşılık bulduğunu gösteriyor. Bu çalışmada içerik modelinin yalnızca veritabanını değil, editörün günlük işini ve ziyaretçinin gördüğü sayfayı da belirlediğini görmeye odaklanıyorum.

Ekip içinde çalışırken bu soruların cevabı tek bir kişide değil, ortak kararlarda şekilleniyor. Benim payıma düşen, o kararların arayüzde, serviste ve veride aynı biçimde karşılık bulmasına katkı vermek.