Memilih PDF generation API terlihat mudah sampai Anda mulai benar-benar mengevaluasi. Ada sekitar 40 vendor, halaman marketing mereka terdengar mirip, dan tradeoff sebenarnya baru terasa setelah beberapa ribu dokumen berjalan di production.

Ini checklist yang bisa Anda bawa ke evaluasi vendor: netral-vendor, ditarik dari insiden nyata yang dialami tim saat procurement dan post-mortem. Ada delapan pertanyaan; jika Anda tidak bisa mendapatkan jawaban jelas untuk semuanya, informasi Anda belum cukup untuk memilih.

1. Format input Anda apa — HTML, JSON, atau template DSL?

Ini pertanyaan paling penting. Jawabannya menentukan apa yang akan ditulis tim Anda — dan apa yang akan mereka debug pada pukul 2 pagi.

HTML/CSS (Puppeteer, DocRaptor, Prince): familiar, fleksibel tanpa batas, mahal saat runtime, sulit dibuat deterministik.
JSON / data terstruktur (gPdf): murah untuk dirender, byte-identical, membutuhkan mapper kecil dari model data Anda ke model dokumen.
Template DSL (PDFKit, ReportLab, Apache PDFBox): kontrol penuh, tanggung jawab penuh — pagination, layout, dan font fallback akan Anda tulis sendiri.

Tidak ada jawaban yang salah secara universal. Yang ada adalah jawaban yang salah untuk tim Anda. Tanyakan kepada engineer Anda: model mana yang ingin mereka debug saat ada bug pagination tiga jam?

2. Berapa cold-start latency — dan apakah dapat diprediksi?

Sebagian renderer boot dalam microseconds (WASM atau native binary). Sebagian boot dalam hitungan seconds (berbasis Chromium). Perbedaannya tidak terlihat sampai Anda mengalami lonjakan traffic.

Yang perlu ditanyakan ke vendor:

“Berapa p99 latency untuk request pertama ke worker yang cold?”
“Berapa lama setelah request terakhir saya sebelum worker menjadi cold lagi?”
“Apakah Anda memublikasikan status page dengan data cold-start?”

Jika mereka tidak bisa menjawab pertanyaan pertama dengan angka, anggap hasilnya buruk.

3. Bagaimana model biaya per render?

Ada tiga pola yang paling sering menggigit tim:

Per-page pricing (Anvil di $0.10/PDF, DocRaptor di$ 89/100K): mudah diprediksi, mudah di-budget, mahal pada skala besar.
Subscription tiers dengan overage (gPdf di $5-12/bulan +$ 0.00005/halaman overage): murah pada volume apa pun, tetapi lebih sulit diproyeksikan untuk usage yang belum pernah diuji.
Compute-based pricing (self-hosted Puppeteer di Lambda): Anda menanggung langsung biaya compute, termasuk cold-start dan memori Chromium.

Hitung tagihan SEBENARNYA pada tiga tingkat traffic: saat ini, 5×, dan 50×, sebelum menandatangani. Bentuk kurva biaya lebih penting daripada angka headline.

4. Apakah output deterministik?

Determinisme — input yang sama → bytes yang sama — terdengar akademis sampai Anda membutuhkannya.

Anda membutuhkannya ketika:

Anda melakukan diff PDF di CI untuk menangkap perubahan template yang tidak disengaja.
Anda menyimpan dokumen berdasarkan e-invoice / hukum pajak: PDF yang Anda simpan dan PDF yang Anda render ulang harus cocok.
Anda membuat hash PDF untuk integritas arsip.
Anda memasukkan output render ke version control untuk legal review.

Renderer berbasis browser (Puppeteer, apa pun yang memakai Chromium) TIDAK deterministik lintas patch version. Renderer native binary (Prince, gPdf) biasanya lebih deterministik. Tanyakan secara eksplisit: “Apakah output bytes saya berubah jika Anda mengirim update renderer?”

5. Bagaimana renderer menangani font, terutama CJK dan RTL?

Ini pertanyaan yang paling sering membuat tim PDF kewalahan.

Failure mode-nya konsisten: Anda launch di home market, font baik-baik saja. Enam bulan kemudian Anda masuk pasar yang memakai script yang glyph-nya tidak dimiliki renderer. PDF mulai mengeluarkan kotak ▢▢▢▢. Pelanggan escalate. Tim Anda menghabiskan dua sprint menambahkan font ke Dockerfile.

Pertanyaan yang perlu ditanyakan:

“Script apa yang dibundel tanpa konfigurasi tambahan? Latin, CJK, Cyrillic, Devanagari, Arabic, Hebrew?”
“Apa yang terjadi ketika glyph tidak dikenal ditemui — fallback atau tofu?”
“Bisakah saya menambahkan custom font saat request, atau harus deploy lebih dulu?”
“Apakah Anda mendukung RTL text shaping?”

Jawaban yang baik: “Kami embed NotoSans CJK dan Noto fallback set; unknown glyph jatuh ke Noto Symbols.” Jawaban yang buruk: “Ya, kami support font.”

6. Profil compliance apa yang didukung?

Jika bisnis Anda mungkin suatu saat:

menerbitkan invoice di Uni Eropa (Factur-X / ZUGFeRD / EN 16931, wajib di DE/FR/IT/PL pada 2026),
mengarsipkan dokumen berdasarkan aturan retensi SOX, HIPAA, atau GDPR (PDF/A),
mengirim medical records (PDF/A-3 dengan attached XML),
menanamkan digital signatures (PAdES),

…maka tanyakan profil compliance apa yang didukung renderer secara native. Jawaban buruk: “Anda bisa menjalankan tool lain untuk convert setelahnya.” Itu berarti pipeline multi-step yang sekarang menjadi tanggung jawab Anda.

Jawaban yang baik biasanya terlihat seperti satu flag — misalnya, gPdf menerima settings.profile: "pdfa-3b" plus block settings.e_invoice dengan standard: "factur_x" dan CII XML tertanam. Built-in jauh lebih ringan secara operasional daripada bolt-on.

7. Apakah rendering stateless? Ke mana dokumen saya pergi setelah dirender?

Dua pertanyaan ini saling terkait.

Stateless rendering berarti request masuk, PDF keluar, tidak ada yang disimpan. Anda mengelola persistence sendiri (S3, database, apa pun). Ini yang Anda inginkan untuk workload berat compliance — renderer tidak pernah menjadi custodian data Anda.

Stateful rendering berarti vendor menyimpan PDF (sering di CDN mereka) dan memberi Anda signed URL. Praktis untuk workflow kasual seperti “kirim link ke pelanggan”, tetapi bermasalah untuk workflow teregulasi karena sekarang ada pihak ketiga yang memegang salinan setiap dokumen yang pernah Anda render.

Tanyakan:

“Apakah rendering stateless secara default?”
“Jika Anda menyimpan dokumen, di mana secara geografis dokumen disimpan?”
“Berapa lama dokumen dipertahankan?”
“Bisakah saya mendapatkan jaminan tertulis soal stateless rendering untuk compliance review?”

Jika jawabannya mengambang, tim privacy/legal Anda akan menjadikannya masalah sembilan bulan kemudian.

8. Apa yang terjadi ketika renderer gagal — dan bagaimana saya mengetahuinya?

Semua renderer kadang gagal. Pertanyaannya:

Bagaimana failure muncul? 500 dengan stack trace? 4xx dengan error terstruktur? PDF kosong?
Apa retry policy-nya? Apakah idempotent? Apakah Anda ditagih untuk render yang gagal?
Instrumentation apa yang disediakan vendor? Status page? Webhook untuk incident? Dashboard p50/p99 per region?
Apakah ada synthetic probe? Apakah vendor menjalankan monitoring sendiri terhadap endpoint publik, atau mengandalkan Anda untuk membuka ticket?

Tes cepat: buka status page vendor sekarang. Jika tidak ada, tidak real-time, atau hanya menampilkan “all systems operational” tanpa detail, itulah tingkat transparency reliability yang akan Anda dapat setelah membeli.

(Sebagai referensi: gPdf memublikasikan /status dengan synthetic probe data + Cloudflare Analytics untuk 7 hari terakhir.)

Skor gPdf terhadap delapan pertanyaan

Karena ini blog kami dan Anda mungkin curiga pertanyaannya condong, berikut scorecard jujur kami:

#	Pertanyaan	Jawaban gPdf
1	Format input	JSON `DocumentRequest` (data terstruktur)
2	Cold start	5-20 ms (V8 isolate, tanpa browser)
3	Model biaya	$0/$ 5/ $8/$ 12 per bulan; $0.00005/halaman overage
4	Determinisme	Byte-identical, dijamin pada engine version yang sama
5	Font	NotoSans CJK + Latin fallback embedded
6	Compliance	PDF/A-1b/2b/3b/4 + attachment Factur-X / ZUGFeRD built-in
7	Stateless	Ya, secara kontraktual — tanpa document storage di mana pun
8	Failure & visibility	Status page publik dengan tren 7 hari; 4xx/5xx terstruktur; idempotent

Di mana kami kalah: Q1, jika input Anda benar-benar HTML yang tidak bisa direfaktor, misalnya laporan user-generated atau template legacy. Untuk kasus itu, DocRaptor atau Prince adalah jawaban yang tepat.

TL;DR

Jangan bertanya “PDF API mana yang terbaik”. Ajukan delapan pertanyaan, beri skor jawabannya, dan pilih vendor yang selaras dengan workload nyata Anda. Tim yang kalah procurement dari rival sedikit lebih murah karena terpukul pertanyaan #5 sembilan bulan kemudian akan mengatakan hal yang sama.

Jika workload Anda kebetulan cocok dengan cara gPdf dibangun, Playground butuh 30 detik untuk dievaluasi. Jika tidak cocok, kami akan dengan senang hati menunjuk tool yang tepat — biasanya DocRaptor untuk masalah berbentuk HTML, Prince untuk self-hosted, atau Puppeteer jika input Anda benar-benar halaman web arbitrer.