Wybór API do generowania PDF wygląda łatwo tylko na początku. Dostawców jest wielu, marketing brzmi podobnie, a realne kompromisy wychodzą dopiero po tysiącach dokumentów w produkcji.
Ta lista pomaga ocenić dostawców. Jest neutralna i oparta na prawdziwych problemach z procurementu, operacji i post-mortem. Bez jasnych odpowiedzi na osiem pytań nie masz jeszcze danych do decyzji.
1. Jaki jest format wejścia: HTML, JSON czy template DSL?
To najważniejsze pytanie, bo określa, co zespół będzie pisał i debugował.
- HTML/CSS (Puppeteer, DocRaptor, Prince): znane, elastyczne, drogie w runtime, trudne do determinizmu.
- JSON / dane strukturalne (gPdf): tanie renderowanie, byte-identical, ale wymaga mapowania danych do modelu dokumentu.
- Template DSL (PDFKit, ReportLab, Apache PDFBox): pełna kontrola i pełna odpowiedzialność za paginację, layout i font fallback.
Nie ma jednej dobrej odpowiedzi. Jest zła odpowiedź dla Twojego zespołu. Zapytaj inżynierów, gdzie wolą debugować trzygodzinny bug paginacji.
2. Jaki jest cold start i czy jest przewidywalny?
WASM i binaria natywne mogą startować w mikrosekundach. Chromium potrafi potrzebować sekund. Różnica ujawnia się przy skokach ruchu.
Zapytaj o p99 pierwszego requestu na zimnym workerze, kiedy worker stygnie ponownie i czy dane są na status page.
3. Jak liczony jest koszt renderu?
Modele:
- Cena za stronę: przewidywalna, ale droga przy skali.
- Subskrypcja + overage: często tania, ale wymaga estymacji usage.
- Compute-based: płacisz za Lambda, kontenery, pamięć Chromium i cold start.
Policz rachunek dla obecnego ruchu, 5x i 50x. Krzywa kosztów jest ważniejsza niż cena reklamowa.
4. Czy output jest deterministyczny?
Ten sam input powinien dawać te same bytes. Potrzebujesz tego do PDF diff w CI, retencji podatkowej, hashy archiwalnych i review prawnego.
Renderery browser-based zwykle nie są deterministyczne między wersjami Chromium. Native renderer wypada lepiej. Zapytaj, czy bytes zmienią się po update silnika.
5. Jak obsługuje fonty, CJK i RTL?
Fonty często psują produkcję dopiero po ekspansji na nowy rynek. Wtedy PDF zaczyna pokazywać □□□□.
Zapytaj, które scripts są wbudowane, czy unknown glyph fallbackuje, czy można podać custom font per request i czy jest RTL shaping.
6. Jakie profile compliance wspiera?
Jeśli możliwe są faktury UE, PDF/A, XML attachment albo podpisy cyfrowe, pytaj o native support. “Konwersja później innym narzędziem” to dodatkowy pipeline do utrzymania.
Dobre odpowiedzi wyglądają jak { profile: "PDF/A-3b" } albo { einvoice: { format: "factur-x", xml: "..." } }.
7. Czy rendering jest stateless? Gdzie trafiają dokumenty?
Stateless rendering przyjmuje request, zwraca PDF i niczego nie zapisuje. Ty kontrolujesz persistence. To preferowane dla workloadów regulowanych.
Stateful rendering zapisuje PDF u vendora i daje signed URL. Wygodne, ale trzeci podmiot trzyma kopie dokumentów.
8. Co dzieje się przy błędzie?
Każdy renderer czasem zawodzi. Sprawdź structured 4xx/5xx, idempotent retry, opłaty za failed render, status page, webhooki, p50/p99 per region i synthetic probes.
Odpowiedzi gPdf
| # | Pytanie | Odpowiedź gPdf |
|---|---|---|
| 1 | Input | JSON DocumentRequest |
| 2 | Cold start | 5-20 ms, V8 isolate, bez browsera |
| 3 | Koszt | $0/$5/$8/$12 miesięcznie; $0.00005/page overage |
| 4 | Determinizm | Byte-identical w tej samej wersji engine |
| 5 | Fonty | NotoSans CJK + Latin fallback embedded |
| 6 | Compliance | PDF/A-1b/2b/3b/4 + Factur-X / ZUGFeRD |
| 7 | Stateless | Tak, bez document storage |
| 8 | Failure | Public status page, structured errors, idempotent |
Jeśli input to naprawdę HTML bez możliwości refaktoryzacji, lepsze mogą być DocRaptor albo Prince.
Podsumowanie
Nie pytaj “które PDF API jest najlepsze”. Zadaj te osiem pytań i wybierz dostawcę pod prawdziwy workload. Dla faktur, potwierdzeń i dokumentów strukturalnych sprawdź gPdf w Playground.