PDF üretim API’si seçmek başlangıçta kolay görünür. Piyasada birçok satıcı vardır, pazarlama sayfaları birbirine benzer ve gerçek farklar ancak üretimde binlerce belge işledikten sonra ortaya çıkar.

Bu liste satıcı değerlendirmesinde kullanılabilir. Belirli bir satıcıyı kayırmaz; satın alma ve post-mortem süreçlerinde görülen gerçek sorunlardan gelir. Sekiz sorunun tamamına net yanıt alamıyorsanız seçim için bilginiz eksiktir.

1. Girdi formatı ne: HTML, JSON veya template DSL?

En önemli soru budur. Ekibinizin ne yazacağını ve gece neyi debug edeceğini belirler.

HTML/CSS (Puppeteer, DocRaptor, Prince): tanıdık, çok esnek, runtime’da pahalı, deterministik yapmak zor.
JSON / yapılandırılmış veri (gPdf): render ucuz, byte-identical, fakat veri modelinden belge modeline mapper gerekir.
Template DSL (PDFKit, ReportLab, Apache PDFBox): tam kontrol, ama pagination, layout ve font fallback sorumluluğu sizde.

Herkes için doğru yanıt yoktur. Ekibiniz için yanlış yanıt vardır. Mühendislere üç saatlik pagination bug’ını hangi modelde çözmek isteyeceklerini sorun.

2. Cold-start latency nedir ve öngörülebilir mi?

WASM veya native binary renderers microsecond düzeyinde başlayabilir. Chromium tabanlı çözümler saniyeler sürebilir. Fark trafik pikinde görünür.

Cold worker ilk request p99’unu, worker’ın ne zaman tekrar cold olduğunu ve status page’de bu verilerin yayınlanıp yayınlanmadığını sorun.

3. Render başına maliyet nasıl modelleniyor?

Yaygın modeller:

Sayfa başı fiyat: öngörülebilir, ama ölçek büyüyünce pahalı.
Abonelik + aşım: birçok hacimde ucuz, ama usage tahmini ister.
Compute-based: Lambda, container, Chromium memory ve cold start size fatura edilir.

Mevcut, 5x ve 50x trafik için gerçek faturayı hesaplayın. Maliyet eğrisi başlıktaki fiyattan önemlidir.

4. Çıktı deterministik mi?

Aynı input, aynı bytes. CI’da PDF diff, vergi/e-invoice saklama, arşiv hash’i ve legal review için gerekir.

Browser-based renderers Chromium sürümleri arasında genelde deterministik değildir. Native renderers daha iyi olur. Engine update sonrası bytes değişir mi diye açıkça sorun.

5. Fonts, CJK ve RTL nasıl ele alınıyor?

Font sorunları en sık production sürprizlerinden biridir. İlk pazarda her şey çalışır; sonra farklı script gerekir ve PDF’de □□□□ görünür.

Hangi script’ler bundled, bilinmeyen glyph fallback yapıyor mu, request ile custom font verilebilir mi ve RTL shaping var mı sorun.

6. Hangi compliance profilleri destekleniyor?

EU invoice, PDF/A arşivi, XML attachment veya digital signature gerekebilirse native support isteyin. “Sonradan başka tool ile convert edin” demek, artık sizin yöneteceğiniz bir pipeline var demektir.

İyi yanıtlar { profile: "PDF/A-3b" } veya { einvoice: { format: "factur-x", xml: "..." } } gibi görünür.

7. Rendering stateless mi? Belgeler nereye gidiyor?

Stateless rendering request’i alır, PDF’i döndürür ve hiçbir şey saklamaz. Persistence sizdedir. Regulated workloads için doğru model budur.

Stateful rendering PDF’i vendor tarafında saklar ve signed URL verir. Kullanışlıdır, ama üçüncü taraf her belgenin kopyasını tutar.

8. Renderer hata verirse ne olur?

Her renderer bazen fail eder. Structured 4xx/5xx var mı, retry idempotent mi, failed render ücretli mi, status page/webhooks/region p50-p99 var mı, synthetic probe çalışıyor mu kontrol edin.

gPdf yanıtları

#	Soru	gPdf yanıtı
1	Input	JSON `DocumentRequest`
2	Cold start	5-20 ms, V8 isolate, browser yok
3	Maliyet	Ayda $0/$5/$8/$12; $0.00005/page overage
4	Determinism	Aynı engine version’da byte-identical
5	Fonts	NotoSans CJK + Latin fallback embedded
6	Compliance	PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD
7	Stateless	Evet, document storage yok
8	Failure	Public status page, structured errors, idempotent

Input gerçekten refactor edilemeyen HTML ise DocRaptor veya Prince daha doğru olabilir.

Özet

“En iyi PDF API hangisi?” diye sormayın. Bu sekiz soruyu sorun, yanıtları puanlayın ve gerçek workload’unuza göre seçin. Invoice, receipt ve structured documents için gPdf’i Playground üzerinde deneyebilirsiniz.