Web

PostScript — E-dergi ve Yayın Sistemi

Bir dergi yalnızca bir web sitesi değil: yazarların, editörlerin ve çizerlerin sırayla dokunduğu bir üretim hattı. PostScript'te bu hattın yazılımını kuruyorum.

Siteyi Aç
Rolüm
Yazılım geliştirme
Dönem
Eylül 2026 — devam ediyor
Durum
Geliştirme aşamasında, 1 Ekim 2026 yayınına hazırlanıyor
Tür
Web uygulaması
PostScript'in halka açık ana sayfası: ilk sayının duyurusu ve yazı alanları.
Okuyucunun gördüğü yarı. Aynı uygulama, aşağıdaki panelin de kendisi.

Genel Bakış

PostScript, herkesin erişebileceği bir e-dergi çıkarmak ve derginin etrafında sosyal bir topluluk kurmak için geliştiriliyor. Ama okuyucunun gördüğü kısım işin yarısı: derginin yayın ve ekip operasyonlarını yürüten yönetim sistemi de aynı uygulamanın içinde.

Derginin tasarımı ve kuruluşu Tuanna Demir'e ait. Ben yazılımın tamamını geliştiriyorum ve ayrıca derginin yönetiminde görev alıyorum.

Problem

Bir sayı çıkarmak tek bir kişinin işi değil. Yazı yazılıyor, okunuyor, gerekiyorsa geri gönderiliyor, onaylanıyor ve yayına alınıyor. Yaklaşık kırk kişilik bir ekibin aynı içeriğe farklı yetkilerle ve farklı aşamalarda dokunması gerekiyordu.

Bunu iki ayrı ürün olarak kurmak, yetki kurallarını iki kez yazmak demekti. Bu yüzden tek bir uygulama kurdum: okuyucunun gördüğü dergi ile ekibin çalıştığı panel aynı veritabanını, aynı yetki kurallarını ve aynı iş mantığını paylaşıyor.

görevli katkı veren kişi
39
yazar
29
editör, biri Lead Editor
6
yönetici
2
Yönetim panelindeki kullanıcı listesi: her satırda bir hesap ve rolü.
Roller veri modelinin içinde: yazar, editör ve yönetici aynı listede, aynı kurallara bağlı. Ekran görüntüsü tamamen sentetik bir demo ortamından.

Dört hesapta çizer işareti var, ama çizerlik ayrı bir rol değil: bu dört kişiden ikisi aynı zamanda yazar. Sistemdeki hesap sayısı 39'dan fazla; yukarıdaki sayı, dergiye görevli olarak katkıda bulunan benzersiz kişi sayısı.

Sistem

Ekip içindeki yol şu: yazar yazısını panelde hazırlayıp incelemeye gönderiyor; kategori editörü okuyup onaylıyor ya da revizyon isteyerek geri gönderiyor; Lead Editor ikinci onayı veriyor; yönetici yazıyı yayın akışına alıyor. Revizyon istenen bir yazı düzeltildikten sonra aynı zincire baştan giriyor.

Bir yazı revizyon istenerek yazara geri gönderilmiş, editörün notuyla birlikte.
Geri gönderme de zincirin bir adımı: not yazıya bağlı kalıyor, yazı düzeltilince aynı sıraya baştan giriyor.

Bu zincir arayüzdeki bir dizi düğme değil. Bir yazının on bir durumu ve aralarında tanımlı geçişleri var; bu listede olmayan hiçbir geçiş sunucuda kabul edilmiyor. Tarayıcıda bir düğmeyi gizlemek, bir yazının yayına çıkmasını engelleyen şey değil.

Editör panelindeki yazı listesi; her satırda yazının o anki durumu.
Aynı listede beş ayrı durum: taslak, incelemede, ana editör onayında, revizyon istendi, yayınlandı. Zincirin on bir durumundan beşi tek karede.

  1. Tek uygulama, iki yüz

    Halka açık dergi ve yönetim paneli tek bir Next.js App Router uygulaması. Yetki kuralları tek yerde tanımlı olduğu için panelde geçerli olan bir kısıt, sitede de aynı şekilde geçerli.

  2. İş mantığı sayfalardan ayrı

    Kurallar 33 servis modülünde toplanıyor. Sayfaların işi veriyi istemek ve göstermek; bir kuralın değişmesi gerektiğinde sayfalar tek tek aranmıyor.

  3. İşin çoğu sunucuda

    Mimari sunucu ağırlıklı kuruldu: tarayıcıya gereğinden fazla kod ve veri gitmiyor, yetki kontrolü de istemciye güvenmek zorunda kalmıyor.

  4. Yayın kapısı hak devrine bağlı

    Bir yazı, imzalanmış hak devri formu olmadan ve eklenen her görselin lisans bilgisi girilmeden yayına alınamıyor. Bu kontrol arayüzde değil, durum değişikliğini yapan tek fonksiyonun içinde. Yönetici yazıyı kabul ettiğinde de iş bitmiyor: kabul bir durak değil, hak devri formunu oluşturup bir sonraki duruma geçiyor.

  5. Roller veriyle birlikte tasarlandı

    45 tablo ve 40 migration, rollerin ve içerik durumlarının zamanla değişeceği varsayılarak kuruldu. Yeni bir rol ya da yeni bir yayın durumu eklemek şemayı baştan yazmayı gerektirmiyor.

Yazarın onay ekranı: kabul edilen metnin özeti, sözleşme sürümü ve imzalanacak cümle.
Yukarıdaki kapının somut hâli. Yönetici yazıyı kabul edince bu form açılıyor; yazar imzalamadan hiçbir geçiş yazıyı yayına götürmüyor.

Teknoloji

Uygulama

  • Next.js 16
  • React 19
  • TypeScript
  • Tailwind CSS

Veri

  • PostgreSQL / Neon
  • Drizzle ORM

Dağıtım

  • Vercel

Güvenlik

  • Argon2id
  • TOTP 2FA
  • Zod
  • Cloudflare Turnstile
  • CSRF
  • Rate limiting
  • CSP

Oturumlar JWT ile değil, veritabanında tutuluyor. Bunun pratik karşılığı şu: bir hesabın yetkisi değiştiğinde ya da bir oturumun kapatılması gerektiğinde karar anında geçerli oluyor, jetonun süresi dolana kadar beklenmiyor. Editör ve yönetici hesaplarında iki adımlı doğrulama (TOTP) zorunlu.

Arayüz bileşenleri hazır bir kütüphaneden gelmiyor; derginin tasarımına göre elle yazıldı.

satır TypeScript
~40.300
sayfa
80
servis modülü
33
veritabanı tablosu
45
migration
40
test, 69 dosyada
685

Mevcut Durum

Proje 6 Eylül 2026'da başladı ve 1 Ekim 2026 yayınına hazırlanıyor. Son ölçümde 69 dosyadaki 685 birim ve entegrasyon testinin tamamı geçiyordu.

Yayınlanmış bir yazının editör görünümü ve geçiş geçmişi.
Bir yazının geçtiği her adım kayıtlı kalıyor — kimin ne zaman hangi durumu değiştirdiği dahil.

Uçtan uca (E2E) testler de var, ancak bu ölçüm sırasında çalıştırılmadı — bu yüzden "tüm testler geçiyor" demiyorum. Dergi henüz yayına açılmadığı için okuyucu, trafik veya erişim sayısı da paylaşmıyorum.

Sıradaki Proje Study — Akıllı YKS Çalışma Sistemi