Todo equipo que necesita imprimir desde un backend tiene la misma primera idea: esto es un problema resuelto, CUPS existe, y un pequeño servicio por delante es un fin de semana de trabajo. Esa estimación no se equivoca sobre el fin de semana. Se equivoca sobre lo que el fin de semana produce.
Respuesta corta: el código es realmente pequeño. A lo que te apuntas de verdad es a alcanzar impresoras detrás de NAT, una cola que sobrevive a los reinicios, entrega exactamente una vez, y alguien que coge el teléfono cuando no imprime nada un sábado por la noche. Autoaloja cuando las impresoras están en tu propia red y tu equipo ya opera infraestructura; compra cuando están en la de otro.
Lo que produce el fin de semana, y lo que no
| Pieza | ¿Un fin de semana? | Realidad |
|---|---|---|
| POST a un endpoint, spool hacia CUPS | Sí | Realmente una tarde |
| Alcanzar una impresora detrás del router de un cliente | No | VPN, redirección de puerto, o un equipo que sale solo |
| Sobrevivir a un reinicio a mitad de trabajo | No | Una cola durable, no un array en memoria |
| No imprimir nunca dos veces el mismo ticket | No | Claves de idempotencia y un almacén para guardarlas |
| Saber que una impresora está caída | No | Latidos, alertas, un turno de guardia |
| Firmware, renovaciones TLS, parches del sistema | No | Continuo, y el ticket favorito de nadie |
La primera fila es la que se estima. Las otras cinco son las que ocupan el calendario durante años.
La pregunta que de verdad decide
No "¿sabemos construirlo?", sino ¿dónde están las impresoras?
Si están en tu propio almacén, en tu red, administradas por tu equipo, autoalojar es razonable. Ya tienes monitorización, ya tienes ventana de mantenimiento, y añadir un spooler de impresión es un coste marginal.
Si están en locales que no controlas, una tienda, la sede de un cliente, una franquicia, una cocina asociada, entonces cada problema arquitectónico de arriba pasa a ser el router de otro, el corte de luz de otro, el "hemos cambiado de operador" de otro. Ninguna cantidad de buen código por tu parte arregla una impresora que no puedes alcanzar, y el arreglo exige un equipo que establezca su propia conexión saliente.
Esa es la verdadera línea divisoria, y no es cuestión de escala. Diez impresoras en un edificio es fácil. Tres impresoras en tres ciudades es el caso difícil.
Dónde se esconde el coste
Atravesar el NAT. Una impresora en la LAN de una tienda no tiene dirección pública. Tus opciones son una VPN por sede, una redirección de puerto por sede, o un equipo que se conecte hacia fuera. Las dos primeras son trabajo administrativo que vuelve en cada apertura de local y en cada cambio de router.
Entrega exactamente una vez. Un trabajo aceptado y luego perdido durante un reinicio es un ticket que falta y que nadie conoce. Un trabajo reintentado tras una impresión parcial es un duplicado. Acertar en ambos exige una cola durable y una clave de idempotencia, que es la parte que los equipos descubren más a menudo en producción que en diseño.
Observabilidad. La impresión falla en silencio por naturaleza: se acaba el papel, el cable se suelta, el router se reinicia. Sin latidos, el fallo aparece como una queja de cliente horas después.
El busca. Esto es lo que decide en la práctica. La impresión falla a las 20:00 del sábado, no a las 11:00 del martes. Un turno de guardia es un coste real y continuo, y rara vez está en la estimación original.
Cuándo autoalojar es lo correcto
Hay buenas razones, y merece la pena decirlas con claridad:
- Un requisito de cumplimiento que impida que los datos de pedido salgan de tu infraestructura. Es una restricción legítima y zanja la cuestión.
- Impresoras en tu propia red, en tus edificios, con un equipo de operaciones ya de guardia por otros motivos.
- Un protocolo o un equipo muy inusual que ningún proveedor soporta, donde escribirías el driver de todos modos.
- Un volumen donde el precio por envío domina de verdad tu economía unitaria, con equipo para absorber la carga operativa.
Si alguno te describe, aloja. El ejercicio de abajo sigue mereciendo la pena, pero la respuesta puede ser perfectamente "nuestro endpoint nos vale, nos lo quedamos", y es un resultado legítimo.
Una forma barata de decidir
Antes de comprometerte, presupuesta con honestidad:
- Días hasta el primer ticket impreso desde tu backend.
- Días hasta el primer ticket impreso en una sede que no administras.
- Quién recibe el aviso el sábado a las 20:00, y qué puede hacer realmente en remoto.
- Qué pasa el día en que se va la persona que lo construyó.
La pregunta 2 es donde suele doblarse la estimación, y la 4 es donde un pequeño servicio interno se convierte en un pasivo. Si las respuestas son cómodas, autoaloja con confianza. Si la 3 no tiene respuesta, has encontrado la restricción.
Una API REST de impresión gestionada mueve las filas dos a seis de la tabla a otro sitio, y te deja la parte que sí es tuya: qué impresora recibe qué documento, y qué dice el ticket. La referencia de maquetación cubre la parte de formato.
Imprime un ticket de prueba con el plan gratuito desde el mismo backend donde ibas a escribir el spooler. Una tarde de comparación cuesta menos que cualquiera de las dos decisiones tomada a ciegas.
También: la impresión fiable de pedidos detalla idempotencia y reintentos, y el comparativo de APIs de impresión en la nube pone las opciones alojadas una al lado de otra.
FAQ
¿Es difícil construir un servidor de impresión propio?
La primera versión es realmente una tarde: aceptar un POST y hacer spool hacia CUPS. Lo que no es una tarde es atravesar el NAT, una cola durable, la entrega exactamente una vez, los latidos y un turno de guardia, y esos cinco son los que se mantienen durante años.
¿Cuándo debo alojar la impresión yo mismo?
Cuando las impresoras están en tu propia red y en tus edificios, cuando una norma de cumplimiento prohíbe que los datos de pedido salgan de tu infraestructura, cuando el hardware es tan inusual que escribirías el driver de todos modos, o cuando el precio por envío domina de verdad tu economía unitaria.
¿Por qué una impresora en la sede de un cliente es mucho más difícil que una en mi almacén?
Está detrás de un router que no administras, sin dirección pública. Alcanzarla implica una VPN o una redirección de puerto por sede, que vuelven en cada apertura y en cada cambio de router, o un equipo que establece su propia conexión saliente.
¿Puedo usar CUPS para impresión en la nube?
CUPS gobierna bien impresoras en una red que controlas. No resuelve alcanzar una impresora en la LAN de otra persona, y esa es justamente la parte que diferencia la impresión en la nube de la impresión local.
¿Qué suele romper una estimación de hacerlo uno mismo?
La segunda sede. La primera impresora en tu propia mesa funciona rápido; la primera impresora en un sitio que no administras es donde la estimación se dobla, porque convierte un problema de código en un problema de red y de soporte.