การเลือก API สำหรับสร้าง PDF ดูเหมือนง่ายจนกว่าจะเริ่มจริง ตลาดมีผู้ให้บริการจำนวนมาก หน้า marketing คล้ายกัน และ tradeoff จริงมักปรากฏหลังจากรันเอกสารหลายพันไฟล์ใน production แล้ว
Checklist นี้ใช้สำหรับประเมิน vendor ได้โดยตรง ไม่ได้เข้าข้างผู้ให้บริการรายใด และมาจากปัญหาจริงใน procurement, operation และ post-mortem ถ้ายังตอบคำถามทั้ง 8 ข้อไม่ได้ชัดเจน ก็ยังไม่ควรตัดสินใจ
1. Input format คือ HTML, JSON หรือ template DSL?
นี่คือคำถามสำคัญที่สุด เพราะมันกำหนดว่าทีมจะเขียนอะไรและต้อง debug อะไรตอนเกิดปัญหา
- HTML/CSS (Puppeteer, DocRaptor, Prince): คุ้นเคย ยืดหยุ่นมาก แต่ runtime แพง และทำ determinism ยาก
- JSON / structured data (gPdf): render ถูก, byte-identical แต่ต้องมี mapper จาก data model ไป document model
- Template DSL (PDFKit, ReportLab, Apache PDFBox): ควบคุมได้เต็มที่ แต่ต้องรับผิดชอบ pagination, layout และ font fallback เอง
ไม่มีคำตอบที่ถูกสำหรับทุกทีม มีแต่คำตอบที่ผิดสำหรับทีมของคุณ ถาม engineer ว่าอยาก debug pagination bug สามชั่วโมงใน model ไหน
2. Cold-start latency เท่าไร และคาดการณ์ได้ไหม?
WASM หรือ native binary อาจ start ในระดับ microseconds ส่วน Chromium-based อาจใช้ seconds ความต่างนี้เห็นชัดเมื่อ traffic spike
ถาม p99 ของ request แรกบน cold worker, worker จะ cold อีกเมื่อไร และมี cold-start data บน status page หรือไม่
3. คิด cost ต่อ render อย่างไร?
โมเดลที่พบบ่อย:
- คิดต่อหน้า: คาดการณ์ง่าย แต่แพงเมื่อ scale
- subscription + overage: ถูกในหลาย volume แต่ต้อง estimate usage
- compute-based: คุณจ่าย Lambda, container, memory ของ Chromium และ cold start เอง
คำนวณ bill ที่ traffic ปัจจุบัน, 5x และ 50x รูปทรงของ cost curve สำคัญกว่าราคา headline
4. Output deterministic หรือไม่?
Input เดิมควรได้ bytes เดิม สิ่งนี้จำเป็นสำหรับ PDF diff ใน CI, retention ด้านภาษี, archive hash และ legal review
Browser-based renderer มักไม่ deterministic ข้าม version ของ Chromium ส่วน native renderer มักดีกว่า ถามตรง ๆ ว่า engine update แล้ว bytes จะเปลี่ยนไหม
5. จัดการ fonts, CJK และ RTL อย่างไร?
Font เป็นปัญหา production ที่เจอบ่อยเมื่อขยายตลาด เริ่มแรกทุกอย่างปกติ แต่พอใช้ script ใหม่ PDF กลายเป็น □□□□
ถามว่า bundle script อะไรมาแล้ว, unknown glyph fallback หรือ tofu, ส่ง custom font ต่อ request ได้ไหม และรองรับ RTL shaping หรือไม่
6. รองรับ compliance profiles ใด?
ถ้าอาจมี EU invoice, PDF/A archive, XML attachment หรือ digital signature ให้ถาม native support “ค่อย convert ด้วย tool อื่น” หมายถึง pipeline เพิ่มที่คุณต้องดูแล
คำตอบที่ดีควรเป็นรูปธรรม เช่น { profile: "PDF/A-3b" } หรือ { einvoice: { format: "factur-x", xml: "..." } }
7. Rendering stateless หรือไม่? Documents ไปไหน?
Stateless rendering รับ request แล้วคืน PDF โดยไม่ store อะไร คุณจัดการ persistence เอง เหมาะกับ regulated workloads
Stateful rendering เก็บ PDF ที่ vendor และคืน signed URL สะดวก แต่ third party มี copy ของทุก document
8. Renderer fail แล้วเกิดอะไรขึ้น?
Renderer ทุกตัว fail ได้ ตรวจสอบ structured 4xx/5xx, retry idempotent, failed render ถูกคิดเงินไหม, status page, webhooks, metric ต่อ region และ synthetic probes
gPdf ตอบอย่างไร
| # | คำถาม | คำตอบของ gPdf |
|---|---|---|
| 1 | Input | JSON DocumentRequest |
| 2 | Cold start | 5-20 ms, V8 isolate, ไม่มี browser |
| 3 | Cost | $0/$5/$8/$12 ต่อเดือน; overage $0.00005/page |
| 4 | Determinism | byte-identical ใน engine version เดียวกัน |
| 5 | Fonts | ฝัง NotoSans CJK + Latin fallback |
| 6 | Compliance | PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD |
| 7 | Stateless | ใช่ ไม่มี document storage |
| 8 | Failure | public status page, structured errors, idempotent |
ถ้า input เป็น HTML ที่ refactor ไม่ได้จริง ๆ DocRaptor หรือ Prince อาจเหมาะกว่า
สรุป
อย่าถามว่า “PDF API ไหนดีที่สุด” ให้ถาม 8 ข้อนี้ ให้คะแนนคำตอบ และเลือกตาม workload จริง หากเป็น invoice, receipt หรือ structured documents ลอง gPdf ได้ใน Playground