Hintergrundaufgaben, die sich selbst erledigen

• Automatische Warteschlangenverarbeitung — Das System prüft alle paar Sekunden auf anstehende Bestellungen. Wenn Bestellungen vorhanden sind, werden sie ohne Verzögerung einzeln verarbeitet. Wenn die Warteschlange leer ist, fällt es auf eine periodische Prüfung zurück — kein manuelles Eingreifen nötig.
• Selbstregulierende Geschwindigkeit — Die Verarbeitung passt sich automatisch an die Arbeitslast an. Volle Warteschlangen werden so schnell wie möglich abgearbeitet; leere Warteschlangen verbrauchen keine Ressourcen. Das System reguliert sein eigenes Tempo ohne Konfiguration.
• Integriertes Control Panel — Eine Weboberfläche ermöglicht Start, Stopp und Überwachung der Verarbeitung in Echtzeit. Verbleibende Bestellungen mit Fortschrittsbalken einsehen, aktuellen Status prüfen und die Warteschlange zurücksetzen — alles auf einem Bildschirm.
• Warteschlangen-Status und Verwaltung — Der Warteschlangenstatus ist als API verfügbar, sodass externe Systeme den Fortschritt abfragen oder Resets programmatisch neben der integrierten UI auslösen können.

• Polling-Reaktor-Registrierung — registerPollingReaktor erstellt einen timer-basierten Reaktor mit konfigurierbarem interval (5 Sekunden) und autoStart: false. Die Plattform verwaltet den Ausführungslebenszyklus — Start, Stopp und Timing werden über eingebaute REST-Endpunkte gesteuert.
• Bedingter Ablauf mit aktorIfElse — Die Kernlogik ist ein einzelnes aktorIfElse: Wenn Bestellungen vorhanden sind (aktorHasOrders), wird eine verarbeitet (aktorProcessOrder); andernfalls wird false zurückgegeben, um Leerlauf zu signalisieren. Der Boolean-Rückgabewert steuert direkt, ob die nächste Ausführung sofort oder verzögert erfolgt.
• Synchrone und asynchrone Aktoren — aktorHasOrders ist eine synchrone createAktorFunction (einfache Array-Prüfung), während aktorProcessOrder eine asynchrone createAktorFunctionAsync ist (simuliert Verarbeitungszeit). Beide Muster koexistieren im selben Graphen.
• Hilfs-Reaktoren als API-Endpunkte — registerReaktorDefinition erstellt zwei zusätzliche Endpunkte: einen für Warteschlangen-Statusabfragen, einen zum Zurücksetzen der Warteschlange. Das sind einfache Reaktoren, die Daten zurückgeben — kein Polling, kein Timer — von der UI zur Echtzeitüberwachung genutzt.
• Integrierte eigene UI — Das public/-Verzeichnis liefert ein Control Panel, gebaut mit reinem JavaScript und Bootstrap. Es nutzt window.getOperaideAuthToken() zur Authentifizierung und aktualisiert sich automatisch alle zwei Sekunden, wenn der Prozessor läuft.

Die Polling Coffee Queue App registriert drei Endpunkte. Der Polling-Reaktor ist der Kern: Sein createReaktor gibt ein aktorIfElse zurück, das auf Bestellungen prüft und entweder eine verarbeitet (true für sofortige Wiederausführung) oder Leerlauf signalisiert (false für Intervallwartung). Zwei Hilfs-Reaktoren stellen Warteschlangenstatus und Reset-Funktionalität als Standard-REST-Endpunkte bereit. Die eigene UI in public/ verbindet alles — sie ruft die Polling-Steuerungs-Endpunkte (Start/Stopp/Status) und die Hilfs-Reaktoren (Warteschlangenstatus/Reset) auf, um ein Echtzeit-Dashboard bereitzustellen. Die gesamte App ist eine einzelne TypeScript-Datei plus die UI-Assets.