DocRaptor is een solide product. Het verpakt Prince, de gouden standaard voor HTML-naar-PDF, in een gehoste REST API met retries, async jobs en goede documentatie. Het bestaat al meer dan tien jaar en is voor veel teams de logische keuze wanneer ze Prince niet zelf willen beheren.
gPdf is een ander soort tool. gPdf accepteert helemaal geen HTML; het neemt gestructureerde JSON aan en rendert direct naar PDF op de Cloudflare-edge. Het lijstprijsverschil bij 100.000 pagina’s per maand is 5 USD/maand (gPdf Basic) vs 89 USD/maand (DocRaptor Basic), ongeveer 18x. Dat verschil is geen tijdelijke introductieprijs. Het is structureel. Deze post legt uit waarom de architectuur die prijs mogelijk maakt, en waar elk product werkelijk past.
De twee architecturen naast elkaar
| Laag | DocRaptor (HTML → PDF) | gPdf (JSON → PDF) |
|---|---|---|
| Invoer | HTML + CSS (met Prince-extensies voor paged media) | DocumentRequest JSON |
| Renderengine | Prince (gecompileerde C++-engine) | Eigen Rust-engine, gecompileerd naar WebAssembly |
| Hosting | Gecentraliseerde DocRaptor-servers (Amerikaanse datacenterregio) | Cloudflare Workers, elke CF-colo (300+ steden) |
| Cold start | Server-side workerpool | V8-isolate-start, enkele milliseconden |
| Compute per render | Layoutpass over HTML/CSS, daarna pagineert Prince | Directe zetting, geen interpretatiepass voor layout |
| p50 per render | ~250-800 ms wall-clock (netwerk + render) | ~3-8 ms (netwerk + render) |
| Outputdeterminisme | Hoog (Prince is volwassen) | Byte-identiek (zelfde JSON → zelfde bytes) |
Als u deze twee kolommen leest als “algemene HTML-printer” tegenover “doelgerichte documentrenderengine”, hebt u de architectuurkeuze al begrepen. Alles daarna, van latency en kosten tot featurelijsten, volgt uit die ene keuze.
De Prince-belasting
Prince is goed. Het doet ook werk dat de meeste factuur-, bon- en etiketprocessen niet nodig hebben: CSS Paged Media implementeren, met paginabreakregels, doorlopende kopteksten, voetnoten, kruisverwijzingen en gegenereerde contentblokken voor willekeurige HTML die een gebruiker kan aanleveren.
Die algemeenheid heeft runtime-kosten. Om willekeurige HTML te pagineren moet de engine:
- HTML parsen en valideren
- De CSS-cascade parsen en oplossen, eventueel met Prince-extensies
- Een renderboom bouwen
- Een layout in meerdere passes uitvoeren, vooral voor tabellen over meerdere pagina’s of kolommen die moeten balanceren
- Kruisverwijzingen tussen pagina’s oplossen
- PDF-objecten uitsturen
De meeste van die passes zijn de kosten van HTML als invoer accepteren. Als uw invoer al gestructureerde data is, wat bijna altijd zo is voordat een factuur in HTML wordt gewikkeld, betaalt u bij elke render voor compute en latency die niets toevoegt aan het einddocument.
gPdf slaat de interpretatiestap voor layout volledig over. De JSON DocumentRequest specificeert de paginaopbouw al structureel: { pages: [{ size, elements: [...] }] }. De renderengine zet elementen, pagineert tabellen en lijsten deterministisch en schrijft PDF. Er is geen CSS-cascade om op te lossen, geen float-layout om te berekenen en geen extra pass voor kruisverwijzingen.
Het resultaat: dezelfde factuur van één pagina die op DocRaptor ongeveer 300 ms kost, kost op gPdf ongeveer 3 ms. gPdf is niet sneller omdat we een snellere Prince hebben geschreven; gPdf is sneller omdat het grootste deel van het Prince-werk niet hoeft te gebeuren.
“Te goedkoop om waar te zijn” is een echt inkoopbezwaar
Laten we dit direct benoemen, omdat het in vrijwel elk B2B-salesgesprek terugkomt.
“5 USD/maand voor 100.000 renders. DocRaptor kost 89 USD. Anvil kost 0,10 USD per PDF, dus 10.000 USD voor hetzelfde volume. Wat klopt hier niet?”
Drie eerlijke redenen waarom dit prijsniveau mogelijk is:
1. We draaien geen browser
DocRaptor spreidt Prince-infrastructuur over klanten. gPdf spreidt één Cloudflare Worker, die op Workers Bundled ongeveer 0,50 USD per miljoen requests kost. Met JSON-vormige invoer gebruikt onze renderengine ongeveer 1,5 ms CPU per render. Tel daar 50% marge bij op en u zit nog steeds in centen per duizend renders. De rekensom is de prijs.
2. We draaien geen control plane
Geen async jobs, geen callbacks, geen retry-queue, geen documentopslag, geen previewlink-UI, geen multi-tenant database. Elke render is één round-trip naar een stateless functie en terug. Daarmee verdwijnt het operationele oppervlak waarvoor de meeste PDF API-bedrijven budgetteren, en dat ook hun prijs rechtvaardigt.
3. Het model filtert de workloads waarop we geld zouden verliezen vanzelf uit
Als uw document echt HTML-naar-PDF nodig heeft, zoals een juridisch contract van 60 pagina’s of een complex CSS Grid-rapport, loopt u in het eerste uur al tegen het JSON-model aan en kiest u waarschijnlijk toch DocRaptor. We hoeven voor die workloads niet defensief te prijzen, omdat ze zichzelf doorverwijzen. We hoeven alleen te prijzen voor de lange, smalle staart van gestructureerde-data-naar-document, waar de kosten per render werkelijk klein zijn.
Samen betekent dat: 5 USD per 100.000 pagina’s is geen verliesleider, maar de werkelijke kostprijs plus marge. We kunnen die prijs aanhouden omdat de onderliggende compute echt zo goedkoop is wanneer er geen browser wordt meegeleverd.
Waar DocRaptor de juiste keuze is
We proberen geen eenzijdige vergelijkingen te schrijven. Dit zijn de gevallen waarin DocRaptor echt wint:
- Uw invoer is HTML die u niet volledig controleert. Door gebruikers gemaakte rapporten, templates van derden, Markdown uit een CMS dat naar HTML wordt gerenderd. U wilt geen JSON-mapper schrijven voor willekeurige invoer.
- U hebt CSS Paged Media-features nodig die Prince ondersteunt. Doorlopende kop- en voetteksten per hoofdstuk, complexe voetnootherloop, named-page-selectors, gegenereerde inhoudsopgaven en indexen. gPdf heeft gestructureerde equivalenten voor de gangbare subset, maar als u leeft in
@page :left-selectors, is Prince uw vriend. - U hebt een contentteam dat HTML/CSS schrijft, geen JSON. Leg geen JSON-auteursproces op aan een niet-engineeringteam. Dat wordt geen prettige werkwijze.
- Async + callbacks + documentopslag als service. DocRaptor slaat gegenereerde PDF’s op en geeft signed URLs voor aflevering. gPdf is strikt stateless; uw eigen code slaat het resultaat op.
Als u in een van deze categorieën valt, blijf bij DocRaptor. Het is dan de juiste tool.
Waar gPdf de juiste keuze is
Het spiegelbeeld:
- Uw invoer is al gestructureerde data (databaserijen, JSON API-gegevens, queueberichten).
- Latency is belangrijk: interactieve checkoutprocessen, realtime verzendetiketten printen, overzichten op aanvraag genereren.
- U geeft om byte-identieke reproduceerbaarheid voor tests, audittrails of e-factuurretentie.
- U bent kostengevoelig bij elk volume boven een paar duizend renders per maand.
- U hebt barcodes nodig (GS1-128, QR, Data Matrix, PDF417, Aztec, MaxiCode) met precisie onder de millimeter. Prince ondersteunt technisch SVG-barcodes, maar ze via HTML/CSS op 0,1 mm totale lengteprecisie renderen is niet triviaal.
- U hebt PDF/A (1b/2b/3b/4) of Factur-X / ZUGFeRD-bijlagen nodig voor naleving.
- U draait liever geen JSON-naar-HTML-naar-PDF-proces wanneer een JSON-naar-PDF-proces volstaat.
Migratie is mechanisch, niet strategisch
Een veelvoorkomende zorg: “Overstappen betekent dat we al onze templates moeten herschrijven.” Meestal is dat niet zo. De meeste HTML-naar-PDF-templates bestaan voor 20% uit layout, die één keer JSON-structuur wordt, en voor 80% uit data-interpolatie, die exact hetzelfde blijft ongeacht wat de renderengine als invoer accepteert.
Praktisch pad:
- Kies één documenttype om te migreren. Begin met het hoogste volume: de grootste besparing en de kleinste blast radius.
- Neem de data-interface van het HTML-template, dus de variabelen die het interpoleert, en schrijf een kleine
mapToDocumentRequest(data)-functie. - Itereer in de Playground tot de output overeenkomt.
- Draai A/B in productie: routeer twee weken lang 5% van het verkeer naar gPdf. Diff de PDF’s. Vergelijk de facturen.
- Rol vooruit of terug op basis van data, niet op onderbuikgevoel.
We hebben teams dit in één sprint zien doen en de volgende maand 90% van hun PDF-rekening zien besparen. We hebben ook teams zien ontdekken dat hun workload echt HTML-naar-PDF was en daarom bij DocRaptor bleef, met onze zegen.
TL;DR
| DocRaptor | gPdf | |
|---|---|---|
| Beste in | HTML → PDF voor willekeurige content | JSON → PDF voor gestructureerde documenten |
| Prijs (100.000 pagina’s/maand) | 89 USD | 5 USD |
| p50-render | 250-800 ms | 3-8 ms |
| Op de edge gedeployed | ❌ gecentraliseerd | ✅ 300+ Cloudflare-colo’s |
| Async + opslag | ✅ inbegrepen | ❌ stateless by design |
| PDF/A + Factur-X | ⚠️ via Prince-extensies | ✅ ingebouwd |
Als uw documenten gestructureerde data zijn die alleen voor de renderengine als HTML worden aangekleed, betaalt u voor een vertaalslag die niet hoeft te bestaan. Probeer de Playground: beschrijf een van uw facturen in JSON, render die in uw browser in minder dan 5 ms en kijk of het verschil overeenkomt met uw verwachting.