La mayoría de comparativas sobre este tema son listas de funciones donde una columna resulta estar toda en verde. Esta se organiza alrededor de las tres preguntas que determinan de verdad qué herramienta puedes usar: sus respuestas descartan opciones mucho antes que cualquier función.
Respuesta corta: pregúntate (1) si algo tiene que correr en la sede, (2) quién inicia la conexión, y (3) si quedas atado a una marca de impresora. Respondidas las tres, normalmente solo quedan una o dos opciones.
Las tres preguntas decisivas
1. ¿Puede correr algo permanentemente en la sede? Un ordenador, un TPV, una Raspberry Pi con tu software. Si sí, PrintNode y QZ Tray te sirven. Si no (porque el local es de tus clientes, porque hay doscientos, o porque allí nadie puede reiniciar nada), necesitas una impresora que se conecte sola.
2. ¿Quién inicia: tu servidor o la impresora? Push significa que tu backend llama a una API y el servicio entrega. Polling significa que la impresora pregunta repetidamente a un servidor que tú alojas. Las arquitecturas de sondeo (CloudPRNT, Epson Server Direct Print) te entregan la disponibilidad, la cola y la semántica de entrega exactamente-una-vez.
3. ¿Cuántas integraciones vas a mantener? Cada fabricante implementa su propio protocolo para su propia gama: CloudPRNT en Star, Server Direct Print en Epson. Es razonable por su parte: venden impresoras, no capas de integración. Pero supone una integración por marca, y un parque deja de ser homogéneo en cuanto abre una segunda sede. El papel de una plataforma de impresión es la capa de encima: un endpoint único sea cual sea el hardware, más los conectores entre un pedido y un ticket que ningún fabricante entrega.
Cara a cara
| Corre en la sede | Iniciador | Hardware | Suelo de latencia | Alojas tú | |
|---|---|---|---|---|---|
| IPP / CUPS nativo | Servidor de impresión | Push, solo LAN | Cualquiera | Red | El servidor |
| QZ Tray | App Java por puesto | Navegador | Cualquiera, local | Inmediato | Nada (pero un certificado) |
| PrintNode | Cliente por sede | Push | Cualquiera | < 1 s | Nada |
| Star CloudPRNT | Nada | La impresora te consulta | Gama Star | Intervalo de sondeo | El endpoint |
| Epson Server Direct Print | Nada | La impresora te consulta | Gama Epson | Intervalo de sondeo | El endpoint |
| Expedy Print | Nada | Push | Cualquiera (nube o adaptador Pi) | < 1 s | Nada |
Leer la tabla honestamente
Nada aquí es malo. Cada opción es la mejor para alguna situación. IPP es la respuesta correcta para una oficina que imprime documentos en una LAN, y meter eso en una API cloud sería absurdo.
La columna «corre en la sede» decide la mayoría de proyectos. Es la que determina si tu carga de soporte crece linealmente con el número de clientes.
La columna «alojas tú» es la que sorprende. Construir un endpoint CloudPRNT lleva una tarde. Operarlo (disponibilidad, cola, reintentos, guardias) es continuo, y rara vez se presupuesta.
La latencia solo importa a veces. Tres segundos de sondeo son irrelevantes para una lista de preparación de almacén y decisivos para un ticket de cocina en pleno servicio.
Elegir en un párrafo
Todo en una LAN y una persona pulsa Imprimir: impresión nativa. Una web app debe alcanzar la impresora del mismo escritorio con comandos crudos: QZ Tray. Cada sede tiene un ordenador mantenido y siempre encendido: PrintNode. Tu parque es todo Star o todo Epson y alojar un endpoint te parece bien: CloudPRNT o Server Direct Print. Tu backend debe imprimir sin supervisión, en sitios que no controlas, sobre el hardware que cada sede tenga: una API push neutral.
Expedy Print está pensado para ese último caso, con API REST, adaptador Raspberry Pi y conectores para Shopify, WooCommerce y Zapier.
FAQ
¿Cuál es el criterio más importante al elegir una API de impresión en la nube?
Si algo tiene que correr en la sede. Esa única pregunta decide si tu carga de soporte crece con cada cliente, y descarta opciones antes de que cualquier comparación de funcionalidades importe.
¿Qué diferencia hay entre impresión push y por sondeo?
Con push, tu backend llama a una API y el servicio entrega el trabajo. Con sondeo, la impresora pregunta una y otra vez a un servidor que alojas tú si hay trabajo, lo que te hace responsable de la disponibilidad y la cola de ese servidor.
¿Qué opciones me atan a una sola marca de impresora?
Star CloudPRNT exige impresoras Star y Epson Server Direct Print exige impresoras Epson. IPP, QZ Tray, PrintNode y Expedy Print son neutrales respecto al fabricante.
¿La latencia importa de verdad?
Depende del caso de uso. Unos segundos son irrelevantes para una lista de picking en un almacén y decisivos para un ticket de cocina en pleno servicio, donde marcan la diferencia entre que el ticket llegue con el pedido o después de que el cliente se haya ido.
¿Puedo usar varias de estas a la vez?
Sí, y muchos equipos lo hacen. Las impresiones que lanza el operador en un mostrador pueden seguir en QZ Tray o en impresión nativa mientras las dirigidas por eventos pasan a una API push.