Elegir una API de generación de PDF parece fácil hasta que empiezas. Hay decenas de proveedores, sus páginas de marketing suenan parecidas y las diferencias reales aparecen cuando ya llevas miles de documentos en producción.
Esta lista sirve para una evaluación de proveedores. No depende de ningún vendedor concreto y está basada en incidentes reales de compra, operación y posmortem. Son ocho preguntas; si no puedes obtener respuestas claras a todas, todavía no tienes información suficiente para decidir.
1. ¿Cuál es el formato de entrada: HTML, JSON o un DSL de plantillas?
Es la pregunta más importante porque define qué escribirá tu equipo y qué depurará a las dos de la mañana.
- HTML/CSS (Puppeteer, DocRaptor, Prince): familiar, muy flexible, caro en tiempo de ejecución y difícil de hacer determinista.
- JSON / datos estructurados (gPdf): barato de renderizar, idéntico byte a byte, pero requiere mapear tu modelo de datos al modelo de documento.
- DSL de plantillas (PDFKit, ReportLab, Apache PDFBox): control total y responsabilidad total; tú gestionas paginación, layout y fallback de fuentes.
No hay una respuesta universalmente correcta. Sí hay una respuesta incorrecta para tu equipo. Pregunta a tus ingenieros en qué modelo preferirían depurar un bug de paginación de tres horas.
2. ¿Cuál es la latencia de arranque en frío y es predecible?
Algunos renderizadores arrancan en microsegundos, sobre todo WASM o binarios nativos. Otros tardan segundos, especialmente los basados en Chromium. La diferencia se nota cuando llega un pico de tráfico.
Pregunta:
- “¿Cuál es vuestro p99 para la primera petición a un worker frío?”
- “¿Cuánto tiempo pasa desde mi última petición hasta que vuelve a estar frío?”
- “¿Publicáis datos de cold start en una página de estado?”
Si no pueden responder con un número, asume que es malo.
3. ¿Cómo se modela el coste por render?
Tres modelos suelen causar sorpresas:
- Precio por página: predecible y fácil de presupuestar, pero caro a escala.
- Suscripción con excedentes: barato en muchos volúmenes, aunque exige estimar bien el uso.
- Precio por cómputo: pagas directamente Lambda, contenedores, memoria de Chromium y cold starts.
Calcula tu factura real en tres escenarios: actual, 5 veces y 50 veces el tráfico. La forma de la curva importa más que el precio destacado.
4. ¿La salida es determinista?
Determinismo significa mismo input, mismos bytes. Parece académico hasta que necesitas comparar PDFs en CI, conservar facturas bajo normativa fiscal, calcular hashes de archivo o revisar documentos legales con control de versiones.
Los renderizadores basados en navegador no suelen ser deterministas entre versiones de Chromium. Los binarios nativos suelen estar mejor posicionados. Pregunta explícitamente: “¿Cambiarán mis bytes si actualizáis el motor?”.
5. ¿Cómo maneja fuentes, CJK y texto RTL?
Este problema causa más escalaciones de lo que parece. Lanzas en tu mercado local, todo se ve bien; seis meses después entras en Japón, India o Oriente Medio y aparecen cuadros □□□□.
Pregunta:
- “¿Qué escrituras están incluidas sin configuración extra?”
- “¿Un glifo desconocido cae a una fuente fallback o se convierte en tofu?”
- “¿Puedo aportar fuentes por petición?”
- “¿Soportáis shaping RTL?”
Una buena respuesta menciona NotoSans CJK, fallback global y comportamiento claro ante glifos desconocidos. “Sí, soportamos fuentes” no basta.
6. ¿Qué perfiles de cumplimiento soporta?
Si algún día emitirás facturas en la UE, archivarás bajo PDF/A, adjuntarás XML médico o necesitarás firmas digitales, pregunta por soporte nativo. “Puedes convertirlo después con otra herramienta” significa que ahora posees una tubería frágil de varios pasos.
Las buenas respuestas suelen ser flags como { profile: "PDF/A-3b" } o { einvoice: { format: "factur-x", xml: "..." } }. Integrado es mucho menos operación que añadido después.
7. ¿El renderizado es sin estado? ¿Dónde van mis documentos?
El renderizado sin estado recibe la petición, emite el PDF y no almacena nada. Tú decides persistencia en S3, base de datos u otro sistema. Es lo que quieres en cargas reguladas.
El renderizado con estado guarda el PDF en la infraestructura del proveedor y te da una URL firmada. Es cómodo para flujos casuales, pero problemático para privacidad, auditoría y compliance.
Pregunta dónde se guarda, cuánto tiempo se retiene y si pueden garantizar por escrito que no almacenan documentos.
8. ¿Qué pasa cuando falla el renderizador?
Todo renderizador falla a veces. Lo importante es cómo lo sabrás.
- ¿Devuelve 4xx/5xx estructurados o un PDF vacío?
- ¿La operación es idempotente?
- ¿Te cobran renders fallidos?
- ¿Hay status page, webhooks y métricas p50/p99 por región?
- ¿El proveedor ejecuta sondas sintéticas propias?
Abre ahora mismo su página de estado. Si no existe o no tiene detalle, esa será la transparencia que tendrás después de comprar.
Cómo responde gPdf
| # | Pregunta | Respuesta de gPdf |
|---|---|---|
| 1 | Entrada | JSON DocumentRequest |
| 2 | Cold start | 5-20 ms, V8 isolate, sin navegador |
| 3 | Coste | $0/$5/$8/$12 al mes; excedente de $0.00005/página |
| 4 | Determinismo | Bytes idénticos bajo la misma versión del motor |
| 5 | Fuentes | NotoSans CJK y fallback latino incluidos |
| 6 | Cumplimiento | PDF/A-1b/2b/3b/4 y Factur-X / ZUGFeRD integrados |
| 7 | Sin estado | Sí, sin almacenamiento de documentos |
| 8 | Fallos | Página pública de estado, errores estructurados e idempotencia |
Donde no ganamos: si tu entrada real es HTML que no puedes refactorizar, DocRaptor o Prince probablemente son mejores.
Resumen
No preguntes cuál es “la mejor API de PDF”. Haz estas ocho preguntas, puntúa las respuestas y elige el proveedor que encaja con tu carga real. Si tu trabajo se parece a facturas, albaranes, recibos o documentos estructurados, Playground permite evaluar gPdf en menos de un minuto.