DocRaptor é um produto competente. Ele encapsula Prince — o motor de referência em HTML para PDF — em uma API REST hospedada, com retries, jobs assíncronos e documentação decente. Existe há mais de uma década e, para muitas equipes, é a escolha óbvia de “não quero operar Prince por conta própria”.

Somos uma ferramenta de outro formato. O gPdf não aceita HTML; ele recebe JSON estruturado e renderiza PDF diretamente na edge da Cloudflare. A diferença de preço de tabela em 100 mil páginas/mês é US $5/mês (gPdf Basic) vs US$ 89/mês (DocRaptor Basic) — cerca de 18×. Essa diferença não é uma promoção de abertura. É estrutural. Este post explica por que a estrutura produz esse preço e onde cada ferramenta realmente se encaixa.

As duas arquiteturas, lado a lado

Camada	DocRaptor (HTML → PDF)	gPdf (JSON → PDF)
Entrada	HTML + CSS (com extensões Prince para paged media)	JSON `DocumentRequest`
Renderizador	Prince (motor C++ compilado)	Motor Rust próprio, compilado para WebAssembly
Hospedagem	Servidores centralizados do DocRaptor (região de data center nos EUA)	Cloudflare Workers, em todos os colos da CF (300+ cidades)
Cold start	Pool de workers no servidor	Boot de isolate V8, milissegundos de um dígito
Computação por render	Passagem de layout sobre HTML/CSS, depois Prince pagina	Composição direta, sem passagem de interpretação de layout
p50 por render	~250-800 ms wall-clock (rede + render)	~3-8 ms (rede + render)
Determinismo da saída	Alto (Prince é maduro)	Byte a byte idêntico (mesmo JSON → mesmos bytes)

Se você lê essas duas colunas como “impressora HTML genérica” versus “renderizador de documentos feito para esse propósito”, já entendeu a decisão arquitetural. Todo o resto (latência, custo e até as listas de recursos) vem depois dessa escolha.

O imposto Prince

Prince é bom. Ele também faz um trabalho de que a maioria dos fluxos de fatura/recibo/etiqueta não precisa: implementar CSS Paged Media — regras de quebra de página, cabeçalhos recorrentes, notas de rodapé, referências cruzadas, caixas de conteúdo gerado — para HTML arbitrário que o usuário possa enviar.

Essa generalidade tem custo em runtime. Para paginar um documento HTML arbitrário, o motor precisa:

Fazer parse e validar o HTML
Fazer parse e resolver a cascata CSS (possivelmente com extensões próprias do Prince)
Construir uma árvore de renderização
Executar layout em múltiplas passagens (especialmente para tabelas que atravessam páginas ou colunas que precisam balancear)
Resolver referências cruzadas entre páginas
Emitir objetos PDF

A maioria dessas passagens é o custo de aceitar HTML como entrada. Se sua entrada já é dado estruturado (e quase sempre é — sua fatura existe como objeto JSON em algum lugar antes de você envolvê-la em HTML), você paga por essas passagens em computação e latência a cada renderização, sem que elas adicionem valor à saída.

O gPdf pula completamente a etapa de interpretação de layout. O JSON DocumentRequest já especifica estruturalmente o layout da página — { pages: [{ size, elements: [...] }] }. O renderizador compõe os elementos, pagina tabelas/listas de forma determinística e emite o PDF. Não há cascata CSS para resolver, layout de floats para calcular nem passagem de resolução de referências cruzadas.

Resultado: a mesma fatura de uma página que leva ~300 ms no DocRaptor leva ~3 ms no gPdf. Não somos mais rápidos porque escrevemos um Prince mais rápido — somos mais rápidos porque não fazemos a maior parte do que Prince faz.

“Barato demais para ser verdade” é uma objeção real em compras

Vamos tratar disso diretamente porque aparece em toda conversa B2B.

“US $5/mês por 100 mil renderizações. DocRaptor custa US$ 89. Anvil cobra US $0,10/PDF (US$ 10.000 pelo mesmo volume). O que há de errado com vocês?”

Três razões honestas pelas quais conseguimos cobrar isso:

1. Não rodamos um navegador

DocRaptor amortiza infraestrutura Prince entre clientes. O gPdf amortiza um Cloudflare Worker, que custa cerca de US$ 0,50/milhão de requisições em Workers Bundled. Com entrada em formato JSON, nosso renderizador usa cerca de 1,5 ms de CPU por render. Some 50% de margem e você ainda fica na faixa de centavos por mil renderizações. A aritmética é o preço.

2. Não rodamos um control plane

Não há jobs assíncronos, callbacks, fila de retry, armazenamento de documentos, interface de link de preview nem banco multi-tenant. Cada renderização é uma única ida e volta para uma função stateless. Isso remove toda a superfície operacional que a maioria das empresas de “PDF API” precisa orçar — e que também justifica o preço delas.

3. O modelo filtra sozinho as cargas em que perderíamos dinheiro

Se seu documento realmente precisa de HTML para PDF (contrato jurídico de 60 páginas, relatório complexo com CSS Grid), você vai esbarrar no modelo JSON na primeira hora e ir para DocRaptor de qualquer forma. Não precisamos precificar defensivamente para essas cargas porque elas se encaminham sozinhas. Só precisamos precificar para a cauda longa, mas estreita, de cargas “dados estruturados para documento”, em que o custo por renderização é genuinamente minúsculo.

Em conjunto: US$ 5/100 mil não é loss leader; é o custo real de bens vendidos mais margem. Podemos manter esse preço indefinidamente porque a computação subjacente é tão barata quando você não embarca um navegador.

Onde DocRaptor é a escolha certa

Tentamos não escrever comparações autoindulgentes. Os casos em que DocRaptor realmente vence:

Sua entrada é HTML que você não controla totalmente. Relatórios gerados por usuários, templates de terceiros, Markdown vindo de CMS e renderizado para HTML. Você não quer escrever um mapper JSON para entrada arbitrária.
Você precisa de recursos de CSS Paged Media suportados pelo Prince. Cabeçalhos/rodapés recorrentes por capítulo, reflow complexo de notas de rodapé, seletores de página nomeados, sumários gerados, índices. O gPdf tem equivalentes estruturados para o subconjunto comum, mas se você vive em seletores @page :left, Prince é seu amigo.
Você tem uma equipe de conteúdo escrevendo HTML/CSS, não JSON. Não imponha um fluxo de autoria em JSON a uma equipe que não é de engenharia. Ela vai odiar você.
Async + callbacks + armazenamento de documentos como serviço. DocRaptor armazena PDFs gerados e entrega URLs assinadas para distribuição. O gPdf é estritamente stateless — seu código armazena o resultado.

Se você está em qualquer um desses grupos, fique no DocRaptor. É a ferramenta certa.

Onde gPdf é a escolha certa

A imagem espelhada:

Suas entradas já são dados estruturados (linhas de banco, dados de API JSON, mensagens de fila).
Latência importa — checkout interativo, impressão de etiquetas em tempo real, geração de extratos sob demanda.
Você se importa com reprodutibilidade byte a byte idêntica para testes / trilhas de auditoria / retenção de e-invoice.
Você é sensível a custo em qualquer volume acima de alguns milhares de renderizações/mês.
Você precisa de códigos de barras (GS1-128, QR, Data Matrix, PDF417, Aztec, MaxiCode) com precisão submilimétrica — Prince tecnicamente aceita códigos de barras em SVG, mas renderizá-los com precisão de comprimento total de 0,1 mm via HTML/CSS não é trivial.
Você precisa de PDF/A (1b/2b/3b/4) ou anexos Factur-X / ZUGFeRD para conformidade.
Você prefere não rodar uma pipeline JSON-para-HTML-para-PDF quando pode rodar uma pipeline JSON-para-PDF.

Migração é mecânica, não estratégica

Uma preocupação comum: “Trocar significa reescrever todos os nossos templates.” Geralmente não. A maioria dos templates HTML para PDF é 20% layout (que vira estrutura JSON uma vez) e 80% interpolação de dados (que é exatamente a mesma, independentemente do que o renderizador recebe).

Caminho prático:

Escolha um tipo de documento para migrar. Comece pelo de maior volume — maior economia, menor raio de impacto.
Pegue a interface de dados do template HTML (as variáveis que ele interpola) e escreva uma pequena função mapToDocumentRequest(data).
Itere no Playground até a saída bater.
Rode A/B em produção: envie 5% do tráfego para o gPdf por duas semanas. Compare os PDFs. Compare as faturas.
Avance ou volte com base em dados, não em sensação.

Já vimos equipes fazerem isso em um único sprint e embolsarem 90% de economia na conta de PDF no mês seguinte. Também vimos equipes perceberem que sua carga era de fato o caso HTML para PDF e permanecerem no DocRaptor — com nossa bênção.

TL;DR

	DocRaptor	gPdf
Melhor em	HTML → PDF para conteúdo arbitrário	JSON → PDF para documentos estruturados
Preço (100 mil páginas/mês)	US$ 89	US$ 5
p50 de render	250-800 ms	3-8 ms
Implantado na edge	❌ centralizado	✅ 300+ colos Cloudflare
Async + armazenamento	✅ incluído	❌ stateless por design
PDF/A + Factur-X	⚠️ via extensões Prince	✅ embutido

Se seus documentos são dados estruturados vestidos de HTML para um renderizador, você está pagando por uma etapa de tradução que não precisa existir. Experimente o Playground — descreva uma das suas faturas em JSON, renderize no navegador em menos de 5 ms e veja se a diferença bate com sua intuição.