PDF generation API বেছে নেওয়া শুরুতে সহজ মনে হয়। বাজারে প্রায় ৪০টি vendor আছে, marketing page-গুলো প্রায় একই রকম শোনায়, আর production-এ কয়েক হাজার document render না করা পর্যন্ত আসল tradeoff বোঝা যায় না।
এই checklist vendor evaluation-এ সরাসরি ব্যবহার করার মতো। এটি vendor-neutral; procurement ও post-mortem-এ teams যে বাস্তব incident দেখে, সেখান থেকেই নেওয়া। আটটি প্রশ্ন। সবগুলোর পরিষ্কার উত্তর না পেলে সিদ্ধান্ত নেওয়ার মতো তথ্য আপনার হাতে নেই।
১. আপনার input format কী: HTML, JSON, নাকি template DSL?
এটাই সবচেয়ে গুরুত্বপূর্ণ প্রশ্ন। এর উত্তর ঠিক করে আপনার team কী লিখবে এবং রাত দুইটায় কী debug করবে।
- HTML/CSS (Puppeteer, DocRaptor, Prince): পরিচিত, সীমাহীনভাবে 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 নিজেকেই লিখতে হবে।
সবার জন্য এক উত্তর নেই। কিন্তু আপনার team-এর জন্য ভুল উত্তর থাকতে পারে। Engineers-কে জিজ্ঞেস করুন: তিন ঘণ্টার pagination bug তারা কোন model-এ debug করতে চাইবে?
২. Cold-start latency কত, এবং তা predictable কি?
কিছু renderer microseconds-এ boot করে, বিশেষ করে WASM বা native binary। কিছু renderer seconds নেয়, বিশেষ করে Chromium-based stack। Traffic spike না আসা পর্যন্ত পার্থক্য চোখে পড়ে না।
Vendor-কে জিজ্ঞেস করুন:
- “Cold worker-এ প্রথম request-এর p99 latency কত?”
- “আমার শেষ request-এর কতক্ষণ পর worker আবার cold হয়?”
- “Cold-start data সহ status page publish করেন?”
প্রথম প্রশ্নের সংখ্যাসহ উত্তর না পেলে ধরে নিন উত্তর ভালো নয়।
৩. Per-render cost কীভাবে model করা হয়?
তিন ধরনের cost model সবচেয়ে বেশি বিপদে ফেলে:
- Per-page pricing (Anvil প্রতি PDF 0.10 USD, DocRaptor 89 USD/100K): predictable, budget করা সহজ, scale-এ ব্যয়বহুল।
- Subscription tiers with overage (gPdf মাসে 5-12 USD + overage প্রতি পৃষ্ঠা 0.00005 USD): যেকোনো volume-এ সস্তা, কিন্তু test না করা usage project করা কঠিন।
- Compute-based pricing (self-hosted Puppeteer on Lambda): cold start ও Chromium memory সহ compute bill সরাসরি আপনার।
Sign করার আগে তিন traffic level-এ actual bill হিসাব করুন: current, 5x, 50x। Headline number-এর চেয়ে cost curve-এর shape বেশি গুরুত্বপূর্ণ।
৪. Output deterministic কি?
Determinism, অর্থাৎ same input থেকে same bytes, academic শোনালেও কিছু workflow-তে এটি বাধ্যতামূলক।
এটি দরকার যখন:
- CI-তে PDF diff করে unintended template change ধরেন।
- E-invoice বা tax law অনুযায়ী document retain করেন; store করা PDF এবং re-render করা PDF মিলতে হবে।
- Archive integrity-এর জন্য PDF hash করেন।
- Legal review-এর জন্য rendered output version-control করেন।
Browser-based renderer (Puppeteer, Chromium stack) patch version বদলালে deterministic থাকে না। Native binary renderer (Prince, gPdf) সাধারণত ভালো। সরাসরি জিজ্ঞেস করুন: “আপনার renderer update হলে কি আমার output bytes বদলাবে?”
৫. Fonts, বিশেষ করে CJK ও RTL, কীভাবে handle করে?
PDF জগতে এই প্রশ্নটাই অনেক team-কে সবচেয়ে বেশি production pain দিয়েছে।
Failure mode প্রায় একই: home market-এ launch করেন, fonts ঠিক। ছয় মাস পরে এমন market-এ যান যেখানে renderer-এর glyph নেই। PDF □□□□ box emit করতে শুরু করে। Customer escalates। Team দুই sprint ধরে Dockerfile-এ fonts যোগ করে।
জিজ্ঞেস করুন:
- “Extra config ছাড়া কোন scripts bundled? Latin, CJK, Cyrillic, Devanagari, Arabic, Hebrew?”
- “Unknown glyph এলে fallback হবে, নাকি tofu?”
- “Request time-এ custom fonts যোগ করা যায়, নাকি আগে deploy করতে হয়?”
- “RTL text shaping support করেন?”
ভালো উত্তর হবে: “আমরা NotoSans CJK এবং Noto fallback set embed করি; unknown glyph Noto Symbols-এ fall through করে।” খারাপ উত্তর: “হ্যাঁ, fonts support করি।”
৬. কোন compliance profiles support করে?
আপনার business যদি কখনো নিচের কোনো কাজ করতে পারে, এখনই প্রশ্নটি করুন:
- EU-তে invoice issue করা (Factur-X / ZUGFeRD / EN 16931; ২০২৬ সালের মধ্যে DE/FR/IT/PL-এ mandatory)
- SOX, HIPAA, বা GDPR retention rules অনুযায়ী document archive করা (PDF/A)
- Medical records submit করা (attached XML সহ PDF/A-3)
- Digital signatures embed করা (PAdES)
তাহলে জিজ্ঞেস করুন renderer কোন compliance profiles natively support করে। খারাপ উত্তর: “পরে আরেকটি tool দিয়ে convert করতে পারেন।” সেটি multi-step pipeline, যা এখন আপনারই চালাতে হবে।
ভালো উত্তর সাধারণত এক flag-এর মতো দেখায়। উদাহরণ হিসেবে gPdf settings.profile: "pdfa-3b" নেয়, সঙ্গে settings.e_invoice block যেখানে standard: "factur_x" এবং embedded CII XML থাকে। Built-in support bolt-on pipeline-এর তুলনায় ops অনেক কমায়।
৭. Rendering stateless কি? Render হওয়ার পর documents কোথায় যায়?
দুটি প্রশ্ন, কিন্তু সম্পর্কিত।
Stateless rendering মানে request আসে, PDF emit হয়, কিছু store হয় না। Persistence আপনি নিজে সামলান: S3, নিজের database, বা অন্য কোনো governed store। Compliance-heavy workloads-এর জন্য এটাই চাই; renderer কখনো আপনার data custodian হয় না।
Stateful rendering মানে vendor PDF store করে, প্রায়ই CDN-এ, এবং signed URL দেয়। Casual workflow-তে সুবিধাজনক, যেমন customer-কে link পাঠানো। Regulated workflow-তে সমস্যা, কারণ third party প্রতিটি rendered document-এর copy রাখে।
জিজ্ঞেস করুন:
- “Rendering কি default-ভাবে stateless?”
- “আপনারা store করলে document কোন geography-তে store হয়?”
- “কতদিন retained থাকে?”
- “Compliance review-এর জন্য stateless rendering-এর written guarantee পাওয়া যাবে?”
উত্তর অস্পষ্ট হলে privacy/legal team কয়েক মাসের মধ্যে এটিকে issue বানাবে।
৮. Renderer fail করলে কী হয়, এবং আমি কীভাবে জানতে পারি?
প্রতিটি renderer কখনো না কখনো fail করে। গুরুত্বপূর্ণ প্রশ্নগুলো হলো:
- Failure কীভাবে surface করে? Stack trace সহ 500? Structured error সহ 4xx? Empty PDF?
- Retry policy কী? Idempotent? Failed render-এর জন্য charge হয়?
- Vendor কী instrumentation দেয়? Status page? Incident webhook? Region-wise p50/p99 dashboard?
- Synthetic probe আছে? Vendor কি public endpoint-এ নিজে monitoring চালায়, নাকি আপনাকে ticket করতে হবে?
একটি দ্রুত test: এখনই vendor-এর status page খুলুন। যদি সেটি না থাকে, real-time না হয়, অথবা detail ছাড়া “all systems operational” দেখায়, purchase-এর পর reliability transparency-ও এমনই হবে।
Reference হিসেবে: gPdf /status publish করে, যেখানে trailing 7 days-এর synthetic probe data এবং Cloudflare Analytics থাকে।
আট প্রশ্নে gPdf-এর score
এটি আমাদের blog, তাই আপনি ভাবতেই পারেন প্রশ্নগুলো আমাদের সুবিধামতো সাজানো। তাই honest scorecard:
| # | প্রশ্ন | gPdf উত্তর |
|---|---|---|
| 1 | Input format | JSON DocumentRequest (structured data) |
| 2 | Cold start | 5-20 ms (V8 isolate, browser নেই) |
| 3 | Cost model | মাসে 0/5/8/12 USD; overage প্রতি পৃষ্ঠা 0.00005 USD |
| 4 | Determinism | একই engine version-এ byte-identical, guaranteed |
| 5 | Fonts | NotoSans CJK + Latin fallback embedded |
| 6 | Compliance | PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD attachment built-in |
| 7 | Stateless | হ্যাঁ, contractually; কোথাও document storage নেই |
| 8 | Failure & visibility | 7-day trend সহ public status page; structured 4xx/5xx; idempotent |
যেখানে আমরা হারি: Q1, যদি আপনার input সত্যিই এমন HTML হয় যা refactor করা যায় না, যেমন user-generated reports বা legacy templates। সে ক্ষেত্রে DocRaptor বা Prince সঠিক উত্তর।
TL;DR
“সেরা PDF API কোনটি?” জিজ্ঞেস করবেন না। এই আট প্রশ্ন করুন, উত্তর score করুন, তারপর আপনার actual workload-এর সঙ্গে যে vendor মেলে তাকে বাছুন। Question #5-এ নয় মাস পরে blindsided হয়ে procurement হারানো team-ও একই কথা বলবে।
আপনার workload যদি gPdf যেভাবে তৈরি, তার সঙ্গে মেলে, Playground দিয়ে ৩০ সেকেন্ডে পরীক্ষা করা যায়। না মিললে আমরা আপনাকে সঠিক tool-এর দিকেই পাঠাব: HTML-shaped problem হলে সাধারণত DocRaptor, self-hosted দরকার হলে Prince, আর input যদি সত্যিই arbitrary web pages হয় তাহলে Puppeteer।