La generació de documents PDF a partir de plantilles HTML és un desafiament recurrent en aplicacions empresarials: factures, informes financers, certificats, contractes. Cada document pot variar dràsticament en mida i volum, des d'uns pocs quilobytes fins a cents de megabytes, i el trànsit sol arribar en ràfegues impredictibles. Davant d'això, moltes arquitectures cauen en la temptació de replicar l'stack d'una gran corporació: Redis, Kafka, Kubernetes, múltiples serveis acoblats. No obstant això, per a equips petits o startups que necessiten aplicacions a mida, hi ha un camí més eficient: una API HTML a PDF basada en Postgres, Chromium i res més. Aquest enfocament minimalista, que prioritza la simplicitat operativa i l' escalabilitat controlada, ha esdevingut un estàndard de facto per als qui entenen que cada dependència extra és un punt potencial de fallada.
La clau està en usar el mateix Postgres que ja emmagatzema les dades de l'aplicació com a cua de treballs asíncrons, gràcies a eines com pg-boss. No necessites Redis ni BullMQ; una sola base de dades recolza tant les dades transaccionals com la planificació de tasques de renderitzat. Això redueix dràsticament la complexitat: una única font de veritat, un únic sistema que monitoritzar i del qual fer còpies de seguretat. Per a un equip petit, això significa menys nits de guàrdia i més temps per centrar-se en el negoci. Quan el volum de peticions és asimètric —per exemple, 10.000 sol·licituds de generació en un minut però només capacitat per processar 60 PDFs per segon— la cua actua com un amortidor natural, desacoblant la taxa d'ingesta de la taxa de processament. Cap pic es perd; els treballs es consumeixen al seu propi ritme.
El maneig de la memòria és un altre punt crític. Un document de 400 MB no es pot carregar complet en RAM sense riscos. La solució consisteix a utilitzar el mode de transmissió de Chromium (ReturnAsStream) juntament amb un buffer de lectura de, per exemple, 1 MB. A mesura que Chrome renderitza, Node.js va extraient fragments i els puja directament a un emmagatzematge S3 mitjançant càrrega multipart. D'aquesta manera, el pic de memòria per document es manté constant (~20 MB) independentment de la mida final. No hi ha acumulació; si S3 s'alenteix, el flux retropropaga la pressió, evitant col·lapses. Aquest patró de streaming amb backpressure és essencial per garantir estabilitat en producció real, més enllà de les demos controlades.
Des del punt de vista de la seguretat, les dades sensibles (noms, adreces, imports) s'han de protegir en repòs i en trànsit. Una pràctica recomanada és xifrar les càrregues útils amb AES-256-GCM abans d'emmagatzemar-les temporalment, usant claus derivades amb HKDF a partir d'un secret mestre i un salt aleatori per cada document. Així, fins i tot si la base de dades es veiés compromesa, no existiria una taula de claus que exposar. A més, els artefactes generats han de tenir una vida útil curta: previsualitzacions que s'eliminen en 24 hores i documents finals en pocs dies. La millor mitigació d'una bretxa és que les dades ja no existeixin. Complementàriament, els webhooks de notificació han d'estar signats amb HMAC-SHA256 i validar-se amb comparació en temps constant per evitar atacs de temporització.
Des d'una perspectiva empresarial, sorgeix la disjuntiva clàssica: construir o comprar. Si la generació de PDF no és el nucli del teu negoci, sinó un mitjà per emetre factures o informes, una API gestionada que cobri cèntims per document pot ser l'opció més rendible. T'estalvies el manteniment de Chromium, les actualitzacions de seguretat, la gestió de l'emmagatzematge i l'operació contínua. No obstant això, quan els volums són tan alts que el cost per document es torna significatiu, o quan la legislació impedeix que les dades surtin de la teva infraestructura, o quan necessites capacitats de renderitzat molt específiques (fonts personalitzades, scripts complexos), llavors construir la teva pròpia API amb Postgres i Chromium es converteix en la decisió encertada. Aquest és el moment d'aplicar aquest blueprint.
En aquest context, comptar amb un soci tecnològic que entengui les subtileses de l' arquitectura cloud i l' optimització de costos és clau. Serveis cloud AWS i Azure ofereixen l'elasticitat necessària per manejar pics de demanda sense sobredimensionar, però requereixen un disseny acurat per no multiplicar la complexitat. Sistemes com PostgreSQL gestionen tant la base de dades principal com la cua de treballs, mentre que S3 (o equivalents) proporcionen emmagatzematge durador per als PDFs generats. La integració amb eines d'intel·ligència artificial pot afegir valor: per exemple, classificar automàticament documents, extreure dades mitjançant OCR o personalitzar plantilles basant-se en perfils d'usuari. Així mateix, la ciberseguretat ha de ser present des del disseny, protegint cada capa del pipeline.
La implementació pràctica sol combinar-se amb frameworks moderns com SvelteKit o Hono per a l'API, i com a cua embeguda a Postgres. No es necessita un cluster de Kubernetes; n'hi ha prou amb unes poques rèpliques de treballadors que comparteixen un pool de connexions a Chromium. El monitoratge se simplifica: una sola base de dades, un sol sistema de logs. Per a equips que desenvolupen programari a mida, aquest tipus d' arquitectura permet iterar ràpid, desplegar en entorns reduïts i escalar horitzontalment quan el negoci ho requereixi, sense arrossegar deute tècnic innecessari.
Pel que fa al rendiment, les proves de càrrega mostren que una màquina virtual compartida (per exemple, 9 de 24 fils) pot ingerir de l'ordre de 5.900 documents per segon a la cua, mentre que el renderitzat s'estabilitza en uns 63 PDFs per segon, limitat pel pool de Chromium. Aquest desfasament de 90 vegades és intencional: la cua absorbeix la ràfega i els treballadors processen al seu ritme natural. La latència P95 sota saturació pot rondar els 5 segons, perfectament acceptable per a processos batch. La clau està en no acoblar la taxa d'acceptació amb la taxa de processament, un error típic en dissenys més acoblats.
Finalment, la decisió de construir una API de PDF interna s' ha d' alinear amb l' estratègia global de l' empresa. Si ja es compta amb un equip que domina Postgres i Node.js, afegir Chromium i S3 no suposa un salt enorme. Però si el core del negoci és un altre, externalitzar la generació de PDF a un servei especialitzat allibera recursos per innovar en el producte principal. En qualsevol cas, entendre els principis d'aquest blueprint —simplicitat, streaming, cues embegudes, seguretat per disseny— proporciona una base sòlida per avaluar qualsevol solució, ja sigui pròpia o de tercers.
En Q2BSTUDIO, ajudem empreses a dissenyar i implementar aquest tipus d'arquitectures, combinant automatització de processos amb bones pràctiques de cloud, intel·ligència artificial i ciberseguretat. Des de la creació d'aplicacions a mida fins a la integració de serveis intel·ligència de negoci com Power BI, passant per la implementació d'agents IA que optimitzin la generació de documents, el nostre enfocament és pragmàtic: menys dependències, més control, i un roadmap clar cap a l'escalabilitat. Perquè al final, el millor sistema és el que pots operar amb un equip petit, mantenir amb confiança i escalar quan arribi el moment.
