İstemci Tarafında PDF İşleme: WebAssembly ile Bellek İçi Belge Yönetimi

Web uygulamalarında belge işleme operasyonları geleneksel olarak Poppler, Ghostscript veya PDFKit gibi yerel ikili dosyaları çalıştıran arka uç mikro servislerine emanet edilmiştir. Bir kullanıcının gizli bir sözleşmeyi birleştirmesi veya tıbbi bir rapordan belirli sayfaları ayıklaması gerektiğinde, standart web iş akışı ham dosyanın tamamının uzak bir bulut sunucusuna yüklenmesini zorunlu kılar.

Kurumsal organizasyonlar, hukuki sözleşmeler ve kişisel kayıtlar söz konusu olduğunda, şifrelenmemiş belge akışlarının üçüncü taraf bulut altyapılarına aktarılması saldırı yüzeyini genişletir ve yasal uyumluluk süreçlerini (KVKK / GDPR sınır ötesi veri aktarımı değerlendirmeleri gibi) karmaşıklaştırır.

LadeStack geliştirici araç setinin bir parçası olan LS PDF’i geliştirirken, tamamen istemci tarafında çalışan bir belge işleme hattı kurguladık. Derlenmiş WebAssembly (Wasm) çekirdeklerini doğrudan tarayıcı belleğindeki Uint8Array arabellekleri üzerinde çalıştırarak, dış sunuculara belge içeriği aktarmaksızın tüm belge dönüşümlerini yerel RAM içerisinde tamamlıyoruz.

Sıfır Yükleme (Zero-Upload) Gizlilik Modeli

Hassas belgelerle çalışırken en sarsılmaz gizlilik güvencesi mimarinin kendisidir: Bir sunucu, kendisine hiç ulaşmayan veriyi sızdıramaz.

GELENEKSEL BULUT PDF ARACI:
[Tarayıcı Dosya Seçimi] ──(Ağ Üzerinden Yükleme)──► [Bulut Sunucusu / DB] ──► [Diske Yazma] ──► [İşleme] ──► [İndirme]

LADESTACK LS PDF (WASM):
[Tarayıcı Dosya Seçimi] ──► [RAM'deki ArrayBuffer] ──► [WASM Çalışma Çekirdeği] ──► [Anında Yerel İndirme]
                                   ▲
                                   └─── Ağ Üzerinden Aktarılan Belge Verisi: 0 Bayt

Dosyaların istemci cihazında kalması kullanıcılara önemli avantajlar sağlar:

• Sıfır Ağ Aktarım Gecikmesi: 150 MB boyutundaki büyük bir belgenin işlenmesi yalnızca yerel işlemci ve RAM hızına bağlıdır; zayıf mobil bağlantı darboğazları ortadan kalkar.
• Azaltılmış Veri Maruziyeti: Belge içerikleri harici ağ noktalarına veya bulut depolama alanlarına aktarılmadığı için üçüncü taraf sunucu depolama riskleri ortadan kalkar (kapsamlı uyumluluk için uç nokta güvenliği ve organizasyonel denetimler yine de gereklidir).
• Çevrimdışı Belge İşleme Güvenilirliği: Web uygulaması paketi ve derlenmiş WebAssembly modülleri tarayıcı önbelleğine (Service Worker veya HTTP önbelleği) alındıktan sonra, belge dönüştürme rutinleri aktif internet bağlantısına ihtiyaç duymadan yerel olarak çalışır.

Bellek İçi İkili İşleme: ArrayBuffer Veri Hattı

Modern web tarayıcıları, yerel dosyaları ham bayt akışları olarak okumak için standart W3C FileReader ve Blob API’lerini sunar. LS PDF bu arayüzlerle doğrudan türlendirilmiş diziler (TypedArray) aracılığıyla haberleşir:

/**
 * Yerel kullanıcı dosyasını bellek içi Uint8Array dizisi olarak okur
 */
export async function readFileAsBinary(file: File): Promise<Uint8Array> {
  const arrayBuffer = await file.arrayBuffer();
  return new Uint8Array(arrayBuffer);
}

Bayt dizisi JavaScript belleğine alındıktan sonra, paylaşılan bellek işaretçisi (pointer) kullanılarak doğrudan WebAssembly doğrusal bellek sınırına aktarılır.

WebAssembly Bellek Eşleme (Marshaling)

C++ veya Rust ile yazılmış yüksek başarımlı belge ayrıştırma algoritmalarını tarayıcı içinde yerel hıza yakın çalıştırmak için JavaScript ana ortamı WebAssembly örneğinde bellek alanı ayırır:

// WebAssembly bellek alanında arabellek tahsis etme
const fileData = await readFileAsBinary(uploadedFile);
const wasmMemory = wasmInstance.exports.memory as WebAssembly.Memory;

// WASM bellek yöneticisinden alan talep et
const ptr = wasmInstance.exports.allocate_buffer(fileData.length);
const memoryView = new Uint8Array(wasmMemory.buffer, ptr, fileData.length);

// Yerel bayt arabelleğini WASM belleğine kopyala
memoryView.set(fileData);

// Belge işleme sürecini başlat (birleştirme, döndürme, sayfa sıralama)
const resultPtr = wasmInstance.exports.process_pdf(ptr, fileData.length);

Veriyi JSON veya Base64 dizgilerine dönüştürmek yerine doğrudan doğrusal bellek adresleri üzerinde işlem yapmak, operasyonların milisaniyeler içinde tamamlanmasını sağlar.

Bellek Yönetimi ve Çöp Toplayıcı Güvenlik Önlemleri

Tarayıcı belleğinde büyük PDF belgeleriyle çalışırken yaşam döngüsünü titizlikle kontrol etmek şarttır. Standart 32-bit WebAssembly (wasm32), 32-bitlik doğrusal adres alanında çalışarak mimari olarak 4 GB ($2^{32}$ bayt) tavan sınırına sahiptir. Uygulamada, tarayıcı motorları (örneğin Chromium içindeki V8), sekme kararlılığını korumak için WebAssembly örneği başına daha da sıkı tahsis sınırları (genellikle 1 GB ila 2 GB) ve genel işlem bellek limitleri uygular. Bellek arabellekleri açıkça serbest bırakılmazsa, çok megabaytlık belgeler üzerindeki ardışık işlemler tarayıcı sekmesinin bellek yetersizliğiyle (OOM) çökmesine neden olur.

Belirtik İşaretçi Serbest Bırakma (Deallocation)

WebAssembly doğrusal belleği için otomatik bir çöp toplayıcı mekanizması bulunmaz. Bu nedenle tahsis edilen her arabelleğin işlem bitiminde manuel olarak serbest bırakılması gerekir:

try {
  const processedLength = wasmInstance.exports.get_result_length();
  const processedBytes = new Uint8Array(
    wasmMemory.buffer,
    resultPtr,
    processedLength
  ).slice(); // Yönetilen JavaScript bellek alanına klonla

  return new Blob([processedBytes], { type: 'application/pdf' });
} finally {
  // WASM yığın arabelleklerini açıkça serbest bırak
  wasmInstance.exports.deallocate_buffer(ptr, fileData.length);
  wasmInstance.exports.deallocate_buffer(resultPtr, processedLength);
}

Elde edilen bayt dilimini standart bir JavaScript Blob nesnesine kopyalayıp WebAssembly yığın alanını hemen serbest bırakarak bellek şişmeleri önlenir ve sistem kararlılığı korunur.

Ağ Aktarımı ve Yerel Yürütme: Teorik Gecikme Modeli

İstemci tarafı belge işlemenin en belirgin yapısal avantajı, ağ üzerinden veri aktarımı aşamasını tamamen ortadan kaldırmasıdır. Geleneksel bulut tabanlı yapılarda, büyük dosyaların sunucuya gönderilmesi ve geri indirilmesi kaçınılmaz bir aktarım gecikmesi yaratır.

Aktarım Gecikmesi Formülü

Ağ aktarım süresi, temel veri iletişimi prensiplerine göre modellenir:

$\text{Aktarım Gecikmesi } (T) = \frac{\text{Veri Boyutu } (L)}{\text{Efektif Bant Genişliği } (R)}$

45 MB (360 Megabit) boyutunda bir belge birleştirme senaryosunun 15 Mbps mobil yükleme kanalındaki hesabı:

$\text{Yükleme Süresi} = \frac{360\text{ Mb}}{15\text{ Mbps}} = 24.0\text{ saniye}$

İşlenmiş sonuç belgesinin ~11.25 MB (90 Megabit) olduğu varsayıldığında, indirme süresi için ek $6.0\text{ saniye}$ gerekir ve sunucu kuyruk gecikmeleri hariç toplam 30.0 saniye kaçınılmaz ağ gecikmesi oluşur.

Mimari Karşılaştırma

Metodolojik Açıklama: Bulut aktarım rakamları, veri boyutu ve bant genişliği parametrelerine dayanan teorik iletim gecikmesi hesaplamasıdır ($T = L / R$). Yerel WebAssembly işleminin gerçek süresi cihazın CPU gücüne ve PDF dosyasının karmaşıklığına bağlıdır; amaç afaki hız iddiaları öne sürmek değil, ağ darboğazının tamamen ortadan kalktığını göstermektir.

LadeStack Ekosisteminde Pratik Uygulamalar

Bu istemci odaklı mimari, LadeStack bünyesindeki belge araçlarına güç vermektedir:

• LS PDF Birleştirici: Sözleşmeleri ve raporları buluta yüklemeden tek bir dosyada birleştirin.
• LS PDF Sayfa Ayırıcı: İhtiyacınız olan sayfa aralıklarını saniyeler içinde ayıklayın ve yerel olarak kaydedin.
• İstemci Tarafı Sıkıştırma: Dahili nesne akışlarını yeniden düzenleyerek ve gereksiz meta verileri temizleyerek dosya boyutunu küçültün.

Gizlilik odaklı araçlarımızın tamamını LadeStack Uygulama Dizini üzerinden inceleyebilir veya güvenlik prensiplerimizi Gizlilik Politikası sayfamızdan okuyabilirsiniz.