Next.js frontend, Express API, Prisma, PostgreSQL, Cloudinary ve DeepL ile yönetilebilir içerik sisteminin nasıl kurgulanacağını anlatıyorum.

Next.js CMS Mimarisi: İçerik, Görsel ve i18n Yönetimi

Bir portfolyo, blog veya kurumsal site büyüdükçe statik JSON dosyaları yetersiz kalır. İşler, blog yazıları, sayfa bileşenleri, görseller ve çeviriler yönetilebilir olmalıdır. Burada amaç yalnızca admin panel eklemek değil, içerik akışını güvenli ve sürdürülebilir hale getirmektir.

API istemcisi

Frontend tarafında API adresini tek bir instance üzerinden yönetmek gerekir. Böylece local, staging ve production ortamlarında component’ler değişmez.

import axios from 'axios'

const axiosInstance = axios.create({
  baseURL: process.env.NEXT_PUBLIC_API_BASE_URL,
  timeout: 15000,
})

export default axiosInstance

Locale parametresi

CMS verisi iki dilde tutulduğunda frontend her locale için ayrı endpoint yazmak zorunda değildir. locale parametresi gönderilir, server ise çeviri alanlarını ana alanların üzerine uygular.

export async function getPortfolioData(locale: string) {
  const response = await axiosInstance.get("/api/projects", {
    params: { locale },
  })

  return response.data
}

Çeviri saklama modeli

Orijinal içerik Türkçe tutulabilir, İngilizce karşılıklar translations.en gibi JSON alanında saklanabilir. Böylece editör ana metni bozmadan çeviriyi görebilir. Yeni kayıt oluşturulurken DeepL ile otomatik çeviri üretilebilir.

const project = {
  title: 'Başlık',
  description: 'Açıklama',
  translations: {
    en: {
      title: 'Title',
      description: 'Description',
    },
  },
}

Medya yönetimi

Görseller admin panelden drag-drop ile yüklenmeli ve medya sağlayıcıda saklanmalıdır. Frontend farklı kullanım yerleri için transform URL üretebilir: thumbnail, banner veya galeri ölçüsü gibi. Böylece editör aynı görseli tekrar tekrar boyutlandırmak zorunda kalmaz.

Markdown editörü

Blog ve proje içeriklerinde HTML yazdırmak editörü yorar. Markdown daha anlaşılırdır; başlık, liste, link, kalın metin ve kod bloğu gibi araçlar admin panelde kısa butonlarla sunulabilir. Teknik bloglarda kod bloklarının çeviri sırasında korunması da ayrıca önemlidir.

Sonuç

İyi bir CMS mimarisi içerik üretimini hızlandırır ama frontend kalitesini bozmaz. API locale’a göre doğru veriyi döndürür, medya sistemi görsel yükünü taşır, Markdown editörü teknik yazıları rahatlatır ve otomatik çeviri iki dilli yayını sürdürülebilir hale getirir.

Uçtan uca düşünmek

Full-stack CMS mimarisinde frontend, API, veritabanı, medya yönetimi ve çeviri sistemi ayrı parçalar gibi görünür; ancak kullanıcı için tek deneyimdir. Admin panelde girilen başlık frontend’de doğru görünmeli, görsel doğru ölçüde basılmalı, çeviri doğru locale’da gelmeli ve içerik editörü teknik detayla boğulmamalıdır.

Veri sözleşmesi

Frontend’in beklediği veri ile API’nin döndürdüğü veri arasında net sözleşme olmalıdır. Eğer proje kartı title, description, category, imageUrl ve slug bekliyorsa API her locale için bu alanları hazır döndürmelidir. Frontend çeviri JSON’unu çözmeye çalışmamalı; server bunu yapmalıdır.

Editör deneyimi

CMS yalnızca geliştiricinin değil, içerik giren kişinin aracıdır. Görsel yükleme sürükle bırak olmalı, Markdown araçları kolay anlaşılmalı, çeviri durumu görünmeli ve hata mesajları teknik olmamalıdır. İyi admin paneli ürünün bakım maliyetini azaltır.

Yayın güvenliği

İçerik sistemi büyüdükçe validation, auth, role kontrolü, medya limitleri, env güvenliği ve yedekleme stratejisi önem kazanır. Küçük portfolyo bile doğru mimariyle kurulduğunda ileride kurumsal site veya içerik platformuna dönüşebilir.

Uygulama planı

Bu yaklaşımı gerçek bir projeye taşırken önce küçük ama doğru çalışan bir çekirdek kurulmalıdır. İlk adım veri modelini netleştirmek, ikinci adım API sözleşmesini belirlemek, üçüncü adım kullanıcı arayüzündeki ana akışı tamamlamak olmalıdır. Bundan sonra otomasyon, çeviri, raporlama veya medya yönetimi gibi ek katmanlar sırayla eklenebilir. Böyle ilerlemek hem geliştirme hızını korur hem de karmaşıklığın erkenden büyümesini engeller.

Ayrıca her teknik kararın kullanıcı veya operasyon karşılığı olmalıdır. Bir tablo, queue, SDK ya da dashboard bileşeni yalnızca teknik olarak doğru olduğu için değil, süreci daha anlaşılır, daha hızlı veya daha ölçülebilir yaptığı için eklenmelidir. Sağlam ürünler bu disiplinle büyür.