Dosya Tabanlı İçerik Yönetimi: Veritabanı Olmadan Ne Kadar İleri Gidilir?

"Veritabanı kullanmadan içerik yönetimi" ilk duyulduğunda amatörce geliyor. Oysa doğru kurulduğunda, orta ölçekli bir kurumsal site için JSON dosyaları hem yeterli hem de birçok açıdan üstün.

Neden dosya?

Üç somut avantaj var:

• Yedekleme basit. Tüm içerik bir klasörde. tar ile arşivlemek yeterli; dump almak, sürüm uyumu kontrol etmek gerekmiyor.
• Bağımlılık yok. Ayrı bir veritabanı sunucusu, bağlantı havuzu, migration aracı ve bunların bakımı ortadan kalkıyor.
• Okunabilirlik. Bir içeriğin ne olduğunu görmek için sorgu yazmıyorsunuz; dosyayı açıp okuyorsunuz.

Çözülmesi gereken dört problem

1. Atomik yazma

Dosyanın ortasında sunucu çökerse yarım JSON kalır ve içerik kaybolur. Çözüm, doğrudan hedefe yazmamak:

// 1. Geçici dosyaya yaz
await fs.writeFile(tmpPath, data);
// 2. Diske gerçekten indiğinden emin ol
await handle.sync();
// 3. Atomik olarak yerine taşı
await fs.rename(tmpPath, targetPath);

rename aynı dosya sistemi içinde atomiktir: ya eski dosya ya yeni dosya görünür, arada bir durum yoktur.

2. Eşzamanlı yazma

İki editör aynı anda aynı kaydı güncellerse biri diğerinin değişikliğini silebilir. Node.js tek iş parçacıklı olsa da await noktaları araya girmeye izin verir.

Çözüm, anahtar bazlı bir kuyruk: aynı kaynağa yapılan yazmalar sıraya girer, farklı kaynaklara yapılanlar paralel devam eder.

3. Okuma performansı

Blog listesi için her istekte 300 dosya okumak kabul edilemez. Bellekte bir indeks tutmak gerekir: uygulama ilk açıldığında dizin bir kez taranır, sonrasında listeler bellekten servis edilir.

İndeks yalnızca yazma işlemlerinde geçersizleştirilir. Bu, tek sunucu senaryosunda kusursuz çalışır.

4. Yol güvenliği

Kullanıcıdan gelen bir slug doğrudan dosya adına dönüşüyorsa, ../../etc/passwd gibi bir değer felaket olur. Her segment beyaz liste ile doğrulanmalı ve çözümlenen mutlak yolun izin verilen kök dizinin altında kaldığı ayrıca kontrol edilmeli.

Sınırlar nerede?

Bu mimari her yerde uygun değil. Şu durumlarda gerçek bir veritabanına geçmek gerekir:

• Birden fazla sunucu aynı veriye yazacaksa (bellek indeksi ve dosya kilidi tek sunucu varsayar)
• Karmaşık ilişkisel sorgular gerekiyorsa
• Kayıt sayısı on binleri aşıyorsa
• İşlem (transaction) bütünlüğü birden çok kayıt arasında zorunluysa

Kurumsal bir tanıtım sitesi, blog ve hizmet kataloğu için bu sınırların hiçbirine yaklaşılmıyor. Karmaşıklığı ihtiyaç doğmadan eklememek, sürdürülebilir mimarinin temel kuralı.