PDF generation API चुनना आसान लगता है, जब तक आप सच में शुरू नहीं करते. बाजार में कई vendor हैं, marketing pages लगभग एक जैसे लगते हैं, और असली tradeoff उत्पादन में हजारों documents render होने के बाद दिखते हैं.
यह checklist vendor evaluation में सीधे इस्तेमाल की जा सकती है. यह किसी vendor के पक्ष में नहीं है; यह उन incidents से निकली है जो teams procurement और post-mortem में बार-बार देखती हैं. आठ सवाल हैं. अगर इन सबका साफ जवाब नहीं मिलता, तो निर्णय लेने के लिए जानकारी अधूरी है.
1. Input format क्या है: HTML, JSON या template DSL?
यह सबसे महत्वपूर्ण सवाल है, क्योंकि यही तय करता है कि आपकी team क्या लिखेगी और रात दो बजे क्या debug करेगी.
- HTML/CSS (Puppeteer, DocRaptor, Prince): familiar, flexible, runtime में महंगा, deterministic बनाना कठिन.
- JSON / structured data (gPdf): render करना सस्ता, byte-identical output, लेकिन data model से document model तक छोटा mapper चाहिए.
- Template DSL (PDFKit, ReportLab, Apache PDFBox): पूरा control, लेकिन pagination, layout और font fallback की पूरी जिम्मेदारी भी आपकी.
सही जवाब universal नहीं होता. गलत जवाब वह है जो आपकी team के लिए गलत हो. Engineers से पूछें कि तीन घंटे के pagination bug को वे किस model में debug करना चाहेंगे.
2. Cold-start latency कितनी है और क्या predictable है?
कुछ renderers microseconds में boot होते हैं, खासकर WASM या native binary. Chromium based systems seconds ले सकते हैं. यह फर्क traffic spike तक अक्सर छिपा रहता है.
Vendor से पूछें:
- “Cold worker की first request p99 latency क्या है?”
- “Last request के कितनी देर बाद worker फिर cold होता है?”
- “क्या status page पर cold-start data publish होता है?”
अगर पहला जवाब number में नहीं है, तो उसे खराब मानें.
3. Per-render cost कैसे model होता है?
तीन models अक्सर problem बनते हैं:
- Per-page pricing: predictable, budget बनाना आसान, scale पर महंगा.
- Subscription + overage: volume पर सस्ता, लेकिन usage estimate चाहिए.
- Compute-based pricing: Lambda/container/Chromium memory/cold start का bill सीधे आपकी जेब से जाता है.
Current, 5x और 50x traffic पर actual bill निकालें. Cost curve headline price से ज्यादा important है.
4. Output deterministic है?
Deterministic का मतलब है same input से same bytes. यह तब जरूरी होता है जब आप CI में PDFs diff करते हैं, tax/e-invoice retention करते हैं, archive hash बनाते हैं, या legal review के लिए rendered output version-control करते हैं.
Browser based renderers Chromium patch versions के बीच deterministic नहीं होते. Native renderers अक्सर बेहतर होते हैं. सीधे पूछें: “Renderer update के बाद मेरे output bytes बदलेंगे?”
5. Fonts, CJK और RTL कैसे संभलते हैं?
Font support PDF systems की सबसे आम production surprises में से एक है. Home market में सब ठीक चलता है; फिर आप ऐसे market में जाते हैं जहाँ CJK, Devanagari या Arabic glyphs चाहिए, और PDF में □□□□ दिखने लगता है.
पूछें:
- “कौन से scripts बिना extra config bundled हैं?”
- “Unknown glyph पर fallback होगा या tofu box?”
- “क्या request time पर custom fonts दे सकते हैं?”
- “क्या RTL shaping supported है?”
अच्छा जवाब NotoSans CJK, fallback set और unknown glyph behavior साफ बताता है. “Fonts supported हैं” काफी नहीं है.
6. कौन से compliance profiles supported हैं?
अगर आपका business कभी EU invoices, PDF/A archival, attached XML medical records या digital signatures करेगा, तो native support पूछें. “बाद में दूसरी tool से convert कर लेना” का मतलब है कि multi-step pipeline अब आपकी जिम्मेदारी है.
अच्छे answers आमतौर पर flag जैसे दिखते हैं: { profile: "PDF/A-3b" } या { einvoice: { format: "factur-x", xml: "..." } }.
7. Rendering stateless है? Documents कहाँ जाते हैं?
Stateless rendering में request आती है, PDF निकलता है, और कुछ store नहीं होता. Persistence आप खुद संभालते हैं. Regulated workloads के लिए यही safer model है.
Stateful rendering में vendor PDF store करता है और signed URL देता है. Casual workflows में यह convenient है, लेकिन regulated workflows में third party हर document की copy रखता है.
पूछें कि document कहाँ store होता है, कितने समय तक रहता है, और क्या stateless guarantee लिखित रूप में मिल सकती है.
8. Renderer fail हो तो क्या होता है?
हर renderer कभी न कभी fail करेगा. जरूरी सवाल ये हैं:
- Failure structured 4xx/5xx है या empty PDF?
- Retry idempotent है?
- Failed renders charge होते हैं?
- Status page, webhooks और region-wise p50/p99 metrics हैं?
- Vendor अपना synthetic monitoring चलाता है?
Vendor की status page अभी खोलें. अगर detail नहीं है, खरीदने के बाद भी transparency यही होगी.
gPdf का scorecard
| # | सवाल | gPdf का जवाब |
|---|---|---|
| 1 | Input | JSON DocumentRequest |
| 2 | Cold start | 5-20 ms, V8 isolate, browser नहीं |
| 3 | Cost | $0/$5/$8/$12 per month; $0.00005/page overage |
| 4 | Determinism | Same engine version पर byte-identical |
| 5 | Fonts | NotoSans CJK + Latin fallback embedded |
| 6 | Compliance | PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD built in |
| 7 | Stateless | हाँ, document storage नहीं |
| 8 | Failure | Public status page, structured errors, idempotent |
जहाँ gPdf fit नहीं है: अगर input सच में existing HTML है जिसे बदल नहीं सकते, तो DocRaptor या Prince बेहतर हो सकते हैं.
सार
“Best PDF API” मत पूछिए. ये आठ सवाल पूछिए, answers score कीजिए, और अपनी workload से match होने वाला vendor चुनिए. अगर आपका काम invoices, receipts, labels या structured documents जैसा है, Playground से gPdf को जल्दी परखा जा सकता है.