Die meisten Vergleiche zu diesem Thema sind Funktionslisten, bei denen eine Spalte zufällig komplett grün ist. Dieser hier ist um die drei Fragen herum gebaut, die tatsächlich bestimmen, welches Werkzeug in Frage kommt: ihre Antworten schließen Optionen aus, lange bevor irgendein Feature zählt.
Kurze Antwort: Fragen Sie (1) ob etwas vor Ort laufen muss, (2) wer die Verbindung initiiert, und (3) ob Sie an eine Druckermarke gebunden sind. Sind die drei beantwortet, bleiben meist nur ein oder zwei Optionen.
Die drei entscheidenden Fragen
1. Kann dauerhaft etwas vor Ort laufen? Ein Rechner, ein Kassenterminal, ein Raspberry Pi mit Ihrer Software. Wenn ja, stehen PrintNode und QZ Tray offen. Wenn nein (weil die Räume Ihren Kunden gehören, weil es zweihundert sind, oder weil dort niemand irgendetwas neu starten kann), brauchen Sie einen Drucker, der sich selbst verbindet.
2. Wer initiiert: Ihr Server oder der Drucker? Push heißt, Ihr Backend ruft eine API auf und der Dienst stellt zu. Polling heißt, der Drucker fragt wiederholt einen Server, den Sie betreiben. Polling-Architekturen (CloudPRNT, Epson Server Direct Print) übergeben Ihnen Verfügbarkeit, Warteschlange und Exactly-once-Semantik.
3. Wie viele Integrationen werden Sie pflegen? Jeder Hersteller implementiert sein eigenes Protokoll für seine eigene Baureihe: CloudPRNT bei Star, Server Direct Print bei Epson. Von ihrer Seite ist das vernünftig: Sie verkaufen Drucker, keine Integrationsschichten. Es bedeutet aber eine Integration pro Marke, und eine Flotte hört auf homogen zu sein, sobald ein zweiter Standort öffnet. Die Aufgabe einer Druckplattform ist die Schicht darüber: ein Endpunkt unabhängig von der Hardware, plus die Konnektoren zwischen Bestellung und Bon, die kein Druckerhersteller liefert.
Direktvergleich
| Läuft vor Ort | Initiator | Hardware | Latenzuntergrenze | Sie betreiben | |
|---|---|---|---|---|---|
| Natives IPP / CUPS | Druckserver | Push, nur LAN | Beliebig | Netzwerk | Den Druckserver |
| QZ Tray | Java-App pro Arbeitsplatz | Browser | Beliebig, lokal | Sofort | Nichts (aber ein Zertifikat) |
| PrintNode | Client pro Standort | Push | Beliebig | < 1 s | Nichts |
| Star CloudPRNT | Nichts | Drucker fragt Sie | Nur Star | Polling-Intervall | Den Endpunkt |
| Epson Server Direct Print | Nichts | Drucker fragt Sie | Nur Epson | Polling-Intervall | Den Endpunkt |
| Expedy Print | Nichts | Push | Beliebig (Cloud-Drucker oder Pi-Adapter) | < 1 s | Nichts |
Die Tabelle ehrlich lesen
Nichts hier ist schlecht. Jede Option ist für irgendeine Situation die beste. IPP ist die richtige Antwort für ein Büro, das Dokumente in einem LAN druckt; das durch eine Cloud-API zu zwingen wäre absurd.
Die Spalte „läuft vor Ort" entscheidet die meisten Projekte. Sie bestimmt, ob Ihre Supportlast linear mit der Kundenzahl wächst.
Die Spalte „Sie betreiben" ist die überraschende. Einen CloudPRNT-Endpunkt zu bauen dauert einen Nachmittag. Ihn zu betreiben (Verfügbarkeit, Warteschlange, Retries, Rufbereitschaft) ist dauerhaft und wird selten eingeplant.
Latenz zählt nur manchmal. Drei Sekunden Polling sind für eine Kommissionierliste egal und für einen Küchenbon im Betrieb entscheidend.
Die Wahl in einem Absatz
Alles in einem LAN und ein Mensch klickt Drucken: nativer Druck. Eine Web-App muss den Drucker am selben Platz mit Rohbefehlen erreichen: QZ Tray. Jeder Standort hat einen gewarteten, dauerhaft laufenden Rechner: PrintNode. Ihre Flotte ist komplett Star oder komplett Epson und ein Endpunkt stört Sie nicht: CloudPRNT oder Server Direct Print. Ihr Backend muss unbeaufsichtigt drucken, an Orten die Sie nicht kontrollieren, auf der Hardware die jeder Standort zufällig hat: eine herstellerneutrale Push-API.
Expedy Print ist für diesen letzten Fall gebaut, mit REST-API, Raspberry-Pi-Adapter und Konnektoren für Shopify, WooCommerce und Zapier.
FAQ
Was ist das wichtigste Kriterium bei der Wahl einer Cloud-Druck-API?
Ob etwas vor Ort laufen muss. Diese eine Frage entscheidet, ob Ihre Supportlast mit jedem Kunden wächst, und schließt Optionen aus, bevor irgendein Funktionsvergleich zählt.
Was ist der Unterschied zwischen Push- und Poll-Druck?
Bei Push ruft Ihr Backend eine API auf und der Dienst stellt den Auftrag zu. Bei Poll fragt der Drucker wiederholt einen Server, den Sie betreiben, ob es Arbeit gibt, womit Sie für Verfügbarkeit und Warteschlange dieses Servers verantwortlich sind.
Welche Optionen binden mich an eine Druckermarke?
Star CloudPRNT setzt Star-Drucker voraus und Epson Server Direct Print setzt Epson-Drucker voraus. IPP, QZ Tray, PrintNode und Expedy Print sind herstellerneutral.
Spielt Latenz wirklich eine Rolle?
Das hängt vom Anwendungsfall ab. Ein paar Sekunden sind für eine Kommissionierliste im Lager belanglos und für einen Küchenbon im laufenden Betrieb entscheidend, wo sie darüber bestimmen, ob der Bon mit der Bestellung ankommt oder erst nachdem die Kundschaft gegangen ist.
Kann ich mehrere davon gleichzeitig einsetzen?
Ja, und viele Teams tun das. Vom Personal ausgelöste Drucke am Tresen können bei QZ Tray oder nativem Druck bleiben, während ereignisgetriebene Drucke auf eine Push-API wechseln.