DocRaptor to kompetentny produkt. Opakowuje PrinceXML, złoty standard silników HTML do PDF, w hostowane REST API z ponawianiem, zadaniami asynchronicznymi i solidną dokumentacją. Istnieje od ponad dekady i dla wielu zespołów jest oczywistym wyborem: “nie chcemy sami utrzymywać PrinceXML”.

gPdf ma inny kształt. W ogóle nie przyjmuje HTML; przyjmuje strukturalny JSON i renderuje PDF bezpośrednio na edge Cloudflare. Różnica ceny katalogowej przy 100 000 stron miesięcznie to 5 USD/miesiąc (gPdf Basic) wobec 89 USD/miesiąc (DocRaptor Basic), czyli około 18 razy. To nie jest promocja na start. To różnica strukturalna. Ten artykuł wyjaśnia, dlaczego taka architektura daje taką cenę i gdzie każde narzędzie naprawdę pasuje.

Dwie architektury obok siebie

Warstwa	DocRaptor (HTML → PDF)	gPdf (JSON → PDF)
Wejście	HTML + CSS (z rozszerzeniami PrinceXML dla paged media)	`DocumentRequest` JSON
Silnik	PrinceXML (kompilowany silnik C++)	Własny silnik Rust skompilowany do WebAssembly
Hosting	Scentralizowane serwery DocRaptor (region centrum danych w USA)	Cloudflare Workers, każde colo Cloudflare (ponad 300 miast)
Cold start	Pula workerów po stronie serwera	Start izolatu V8, pojedyncze milisekundy
Obliczenia na render	Przebieg układu po HTML/CSS, potem paginacja w PrinceXML	Bezpośredni skład, bez przebiegu interpretacji układu
p50 na render	około 250-800 ms czasu całkowitego (sieć + render)	około 3-8 ms (sieć + render)
Determinizm wyjścia	Wysoki (PrinceXML jest dojrzały)	Bajtowo identyczny (ten sam JSON → te same bajty)

Jeśli czytasz te dwie kolumny jako “ogólna drukarka HTML” kontra “wyspecjalizowany generator dokumentów”, rozumiesz już decyzję architektoniczną. Wszystko inne, od latencji i kosztu po listę funkcji, wynika z tej jednej decyzji.

Podatek PrinceXML

PrinceXML jest dobry. Wykonuje też pracę, której większość procesów faktur, paragonów i etykiet nie potrzebuje: implementuje CSS Paged Media, czyli reguły łamania stron, bieżące nagłówki, przypisy, odwołania, generowane bloki treści, dla dowolnego HTML, który użytkownik może mu podać.

Ta ogólność ma koszt w czasie działania. Aby spaginować dowolny dokument HTML, silnik musi:

Sparsować i zweryfikować HTML
Sparsować i rozwiązać kaskadę CSS, potencjalnie z rozszerzeniami PrinceXML
Zbudować drzewo renderowania
Wykonać wieloprzebiegowy układ, zwłaszcza dla tabel przechodzących przez strony albo kolumn wymagających balansowania
Rozwiązać odwołania między stronami
Wyemitować obiekty PDF

Większość tych przebiegów to koszt przyjmowania HTML jako wejścia. Jeżeli Twoje wejście jest już strukturalnymi danymi, a prawie zawsze jest, bo faktura istnieje jako obiekt JSON, zanim opakujesz ją w HTML, płacisz za te przebiegi w obliczeniach i latencji przy każdym renderze. Nie dodają one wartości do wyniku.

gPdf całkowicie pomija etap interpretowania układu. JSON DocumentRequest już strukturalnie opisuje układ strony: { pages: [{ size, elements: [...] }] }. Silnik składa elementy, deterministycznie paginuje tabele i listy, a następnie emituje PDF. Nie ma kaskady CSS do rozwiązywania, układu floatów do liczenia ani przebiegu odwołań między stronami.

Rezultat: ta sama jednostronicowa faktura, która w DocRaptor zajmuje około 300 ms, w gPdf zajmuje około 3 ms. Nie jesteśmy szybsi dlatego, że napisaliśmy szybszy PrinceXML. Jesteśmy szybsi, bo nie robimy większości pracy, którą PrinceXML musi wykonać.

“Za tanio, żeby było prawdziwe” to realna obiekcja zakupowa

Warto odpowiedzieć na to wprost, bo pojawia się w prawie każdej rozmowie B2B.

“5 USD/miesiąc za 100 000 renderów. DocRaptor kosztuje 89 USD. Anvil kosztuje 0,10 USD/PDF, czyli 10 000 USD za ten sam wolumen. Co jest z wami nie tak?”

Trzy uczciwe powody, dla których możemy tak wyceniać usługę:

1. Nie uruchamiamy przeglądarki

DocRaptor amortyzuje infrastrukturę PrinceXML między klientami. gPdf amortyzuje jednego Cloudflare Workera, który na Workers Bundled kosztuje około 0,50 USD za milion żądań. Przy wejściu w kształcie JSON nasz silnik zużywa około 1,5 ms CPU na render. Nawet po dodaniu 50% marży nadal jesteśmy w okolicach centów za tysiąc renderów. Arytmetyka jest ceną.

2. Nie utrzymujemy płaszczyzny sterowania

Nie ma zadań asynchronicznych, callbacków, kolejki ponowień, przechowywania dokumentów, interfejsu linków podglądu ani wielodostępnej bazy danych. Każdy render to jedna runda do bezstanowej funkcji i z powrotem. To usuwa cały obszar operacyjny, na który większość firm “PDF API” planuje budżet i którym uzasadnia cenę.

3. Model sam odsiewa obciążenia, na których przegralibyśmy kosztowo

Jeśli dokument naprawdę potrzebuje HTML do PDF, na przykład 60-stronicowa umowa prawna albo złożony raport CSS Grid, odbijesz się od modelu JSON w pierwszej godzinie i i tak pójdziesz do DocRaptor. Nie musimy defensywnie wyceniać tych obciążeń, bo same wybierają inną ścieżkę. Musimy wyceniać tylko długi, ale wąski ogon procesów “strukturalne dane do dokumentu”, gdzie koszt pojedynczego renderu jest faktycznie bardzo niski.

Razem: 5 USD za 100 000 stron nie jest sprzedażą poniżej kosztów. To realny koszt wytworzenia plus marża. Możemy utrzymywać taki poziom bezterminowo, bo bazowe obliczenia są tak tanie, gdy nie wysyłasz przeglądarki.

Gdzie DocRaptor jest właściwym wyborem

Nie chcemy pisać jednostronnych porównań. Przypadki, w których DocRaptor naprawdę wygrywa:

Wejściem jest HTML, którego nie kontrolujesz w pełni. Raporty użytkowników, szablony stron trzecich, Markdown z CMS wyrenderowany do HTML. Nie chcesz pisać mappera JSON dla dowolnego wejścia.
Potrzebujesz funkcji CSS Paged Media obsługiwanych przez PrinceXML. Bieżące nagłówki i stopki per rozdział, złożone przelewanie przypisów, nazwane selektory stron, generowane spisy treści, indeksy. gPdf ma strukturalne odpowiedniki dla najczęstszej części, ale jeżeli żyjesz w selektorach @page :left, PrinceXML jest właściwym narzędziem.
Masz zespół treści, który pisze HTML/CSS, nie JSON. Nie narzucaj autorskiego procesu JSON zespołowi nietechnicznemu. Będzie to dla niego złe doświadczenie.
Asynchroniczność, callbacki i przechowywanie dokumentów jako usługa. DocRaptor przechowuje wygenerowane PDF-y i daje podpisane URL-e do dostarczenia. gPdf jest z założenia bezstanowy; wynik przechowuje Twój kod.

Jeżeli jesteś w którejkolwiek z tych grup, zostań przy DocRaptor. To właściwe narzędzie.

Gdzie gPdf jest właściwym wyborem

Lustrzane odbicie:

Dane wejściowe są już strukturalne: wiersze bazy danych, dane JSON API, wiadomości z kolejki.
Latencja ma znaczenie: interaktywny checkout, druk etykiet w czasie rzeczywistym, generowanie wyciągów na żądanie.
Zależy Ci na bajtowo identycznej powtarzalności dla testów, śladów audytowych albo retencji e-faktur.
Koszt ma znaczenie przy dowolnym wolumenie powyżej kilku tysięcy renderów miesięcznie.
Potrzebujesz kodów kreskowych (GS1-128, QR, Data Matrix, PDF417, Aztec, MaxiCode) z precyzją poniżej milimetra. PrinceXML technicznie obsłuży kody w SVG, ale utrzymanie długości całkowitej z dokładnością 0,1 mm przez HTML/CSS nie jest trywialne.
Potrzebujesz PDF/A (1b/2b/3b/4) albo załączników Factur-X / ZUGFeRD dla procesów zgodności.
Wolisz nie uruchamiać potoku JSON do HTML do PDF, gdy możesz uruchomić potok JSON do PDF.

Migracja jest mechaniczna, nie strategiczna

Częsta obawa brzmi: “Zmiana oznacza przepisanie wszystkich szablonów”. Zwykle nie. Większość szablonów HTML do PDF to 20% układu, który raz staje się strukturą JSON, i 80% interpolacji danych, która jest dokładnie taka sama niezależnie od tego, co przyjmuje silnik.

Praktyczna ścieżka:

Wybierz jeden typ dokumentu do migracji. Zacznij od tego o największym wolumenie: największe oszczędności, najmniejszy promień zmian.
Weź interfejs danych szablonu HTML, czyli zmienne, które interpoluje, i napisz małą funkcję mapToDocumentRequest(data).
Iteruj w Playground, aż wynik będzie zgodny.
Uruchom A/B w produkcji: skieruj 5% ruchu do gPdf przez dwa tygodnie. Porównaj PDF-y. Porównaj rachunki.
Idź dalej albo wycofaj zmianę na podstawie danych, nie intuicji.

Widzieliśmy zespoły, które zrobiły to w jednym sprincie i w następnym miesiącu obniżyły rachunek za PDF o 90%. Widzieliśmy też zespoły, które odkryły, że ich obciążenie faktycznie jest przypadkiem HTML do PDF i zostały przy DocRaptor. To też jest poprawna decyzja.

TL;DR

	DocRaptor	gPdf
Najlepszy do	HTML → PDF dla dowolnej treści	JSON → PDF dla strukturalnych dokumentów
Cena (100 000 stron/miesiąc)	89 USD	5 USD
p50 renderu	250-800 ms	3-8 ms
Wdrożenie na edge	❌ scentralizowane	✅ ponad 300 colo Cloudflare
Asynchroniczność + przechowywanie	✅ wliczone	❌ bezstanowy z założenia
PDF/A + Factur-X	⚠️ przez rozszerzenia PrinceXML	✅ wbudowane

Jeżeli Twoje dokumenty to strukturalne dane przebrane za HTML dla silnika renderującego, płacisz za krok tłumaczenia, który nie musi istnieć. Wypróbuj Playground: opisz jedną ze swoich faktur w JSON, wyrenderuj ją w przeglądarce poniżej 5 ms i sprawdź, czy różnica zgadza się z Twoją intuicją.