Memilih API pembuatan PDF tampak mudah sampai Anda mulai. Ada banyak vendor, halaman marketing terdengar mirip, dan tradeoff nyata baru muncul setelah ribuan dokumen berjalan di produksi.
Checklist ini bisa dipakai dalam evaluasi vendor. Isinya netral dan berasal dari masalah nyata yang sering muncul saat procurement dan post-mortem. Ada delapan pertanyaan; jika jawabannya tidak jelas, Anda belum punya cukup informasi untuk memilih.
1. Format input: HTML, JSON, atau template DSL?
Ini pertanyaan terpenting karena menentukan apa yang akan ditulis tim Anda dan apa yang akan mereka debug saat insiden.
- HTML/CSS (Puppeteer, DocRaptor, Prince): familiar, sangat fleksibel, mahal saat runtime, sulit dibuat deterministik.
- JSON / data terstruktur (gPdf): murah untuk render, byte-identical, tetapi perlu mapper dari data bisnis ke model dokumen.
- Template DSL (PDFKit, ReportLab, Apache PDFBox): kontrol penuh, tetapi pagination, layout, dan fallback font menjadi tanggung jawab Anda.
Tidak ada jawaban benar universal. Ada jawaban yang salah untuk tim Anda. Tanyakan model mana yang paling mereka inginkan saat harus debug bug pagination selama tiga jam.
2. Berapa cold-start latency dan apakah bisa diprediksi?
Renderer WASM atau native binary bisa start dalam microseconds. Renderer berbasis Chromium bisa butuh seconds. Selisih ini terasa saat trafik melonjak.
Tanyakan p99 untuk request pertama pada worker dingin, kapan worker menjadi dingin lagi, dan apakah data cold start dipublikasikan di status page. Jika tidak ada angka, anggap buruk.
3. Bagaimana biaya per render dihitung?
Model umum:
- Per halaman: mudah diprediksi, tetapi mahal di skala besar.
- Subscription + overage: murah untuk banyak volume, tetapi butuh estimasi usage.
- Compute-based: Anda membayar Lambda, container, memori Chromium, dan cold start.
Hitung biaya untuk traffic saat ini, 5x, dan 50x. Bentuk kurva biaya lebih penting daripada angka headline.
4. Apakah output deterministik?
Input yang sama harus menghasilkan bytes yang sama. Ini penting untuk PDF diff di CI, retensi pajak, hash arsip, dan review legal.
Renderer berbasis browser sering tidak deterministik antar versi Chromium. Renderer native biasanya lebih baik. Tanyakan apakah bytes akan berubah saat engine diperbarui.
5. Bagaimana font, CJK, dan RTL ditangani?
Masalah font sering muncul terlambat. Semua baik di pasar awal, lalu ekspansi ke script baru membuat PDF menampilkan □□□□.
Tanyakan script apa yang sudah dibundel, apa yang terjadi pada glyph tak dikenal, apakah custom font bisa dikirim per request, dan apakah RTL shaping didukung.
6. Profil compliance apa yang didukung?
Jika ada kemungkinan e-invoice EU, arsip PDF/A, XML attachment, atau digital signature, tanyakan dukungan native. “Konversi dengan tool lain nanti” berarti pipeline tambahan yang harus Anda rawat.
Jawaban baik terlihat seperti { profile: "PDF/A-3b" } atau { einvoice: { format: "factur-x", xml: "..." } }.
7. Apakah rendering stateless? Ke mana dokumen saya pergi?
Rendering stateless menerima request, mengeluarkan PDF, dan tidak menyimpan apa pun. Anda mengatur persistence sendiri. Ini paling cocok untuk workload regulasi.
Rendering stateful menyimpan PDF pada vendor dan memberi signed URL. Praktis, tetapi membuat pihak ketiga memegang salinan setiap dokumen.
8. Apa yang terjadi saat renderer gagal?
Semua renderer bisa gagal. Periksa apakah error terstruktur, retry idempotent, render gagal ditagih, status page tersedia, dan vendor menjalankan synthetic probe.
Skor gPdf
| # | Pertanyaan | Jawaban gPdf |
|---|---|---|
| 1 | Input | JSON DocumentRequest |
| 2 | Cold start | 5-20 ms, V8 isolate, tanpa browser |
| 3 | Biaya | $0/$5/$8/$12 per bulan; $0.00005/page overage |
| 4 | Determinisme | Byte-identical pada versi engine yang sama |
| 5 | Font | NotoSans CJK + Latin fallback embedded |
| 6 | Compliance | PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD |
| 7 | Stateless | Ya, tanpa penyimpanan dokumen |
| 8 | Failure | Status page publik, error terstruktur, idempotent |
Jika input Anda benar-benar HTML yang tidak bisa diubah, DocRaptor atau Prince mungkin pilihan yang lebih tepat.
Ringkasnya
Jangan bertanya “API PDF mana yang terbaik”. Ajukan delapan pertanyaan ini, nilai jawabannya, dan pilih vendor sesuai workload nyata. Untuk invoice, resi, label, dan dokumen terstruktur, coba gPdf di Playground.