Polling-Pattern: Intervallbasierte Datenaktualisierung sauber in Alpine.js implementieren

1. Wann Polling trotz SSE und WebSocket die richtige Wahl ist

Server-Sent Events und WebSocket lösen das Aktualitätsproblem eleganter, bringen aber auch mehr Infrastrukturaufwand mit: eine dauerhaft offene Verbindung pro Client, spezielle serverseitige Unterstützung und in vielen Setups zusätzliche Konfiguration bei Reverse-Proxys oder Load-Balancern. Für Daten, die sich selten ändern oder bei denen eine Verzögerung von einigen Sekunden völlig unproblematisch ist, etwa ein Dashboard mit stündlich aktualisierten Reports, ist dieser Mehraufwand oft schlicht nicht gerechtfertigt.

Polling bleibt außerdem die pragmatischere Wahl, wenn die bestehende Infrastruktur, etwa ein klassisches PHP-FPM-Setup ohne Unterstützung für lang laufende Verbindungen, den Betrieb vieler gleichzeitig offener Streams erschwert. Ein sauber implementiertes Polling mit angemessenem Intervall, Backoff und Visibility-Pause erreicht in solchen Fällen einen guten Kompromiss zwischen Einfachheit und akzeptabler Serverlast.

2. setInterval sauber mit init() und destroy() verwalten

Der Klassiker unter den Fehlerquellen bei Polling in Alpine ist ein setInterval, das in init() gestartet, aber nie wieder gestoppt wird. Sobald die Komponente aus dem DOM entfernt wird, etwa weil ein x-if sie ausblendet, läuft der Intervall-Timer im Hintergrund munter weiter, hält dabei über den Closure-Kontext eine Referenz auf die eigentlich längst nicht mehr benötigte Komponente am Leben und produziert weiterhin Requests gegen einen Endpunkt, dessen Ergebnis niemand mehr sieht.

Die saubere Lösung besteht darin, die von setInterval zurückgegebene Timer-ID konsequent auf this zu speichern und im destroy()-Hook der Komponente mit clearInterval wieder aufzuräumen. Alpine ruft destroy() automatisch auf, sobald das zugehörige Element entfernt wird, wodurch dieser Aufräumschritt zuverlässig greift, ohne dass er an anderer Stelle im Code manuell ausgelöst werden müsste.

Alpine.data('orderStatusPoller', (orderId) => ({
  status: null,
  intervalId: null,

  init() {
    this.fetchStatus();
    this.intervalId = setInterval(() => this.fetchStatus(), 5000);
  },

  async fetchStatus() {
    const response = await fetch(`/api/orders/${orderId}/status`);
    this.status = await response.json();
  },

  destroy() {
    clearInterval(this.intervalId);
  },
}));

3. Grundimplementierung eines robusten Polling-Loops

Über das reine Starten und Stoppen hinaus lohnt sich eine kleine Erweiterung: eine Prüfung, ob der vorherige Request bereits abgeschlossen ist, bevor der nächste gestartet wird. Ohne diese Prüfung kann bei einem langsamen Server oder einem kurzzeitig blockierten Endpunkt ein neuer Request starten, während der vorherige noch läuft, wodurch sich überlappende Anfragen anhäufen, deren Antworten in unvorhersehbarer Reihenfolge eintreffen.

Ein einfaches inFlight-Flag löst dieses Problem zuverlässig: Solange eine Anfrage noch aussteht, wird der nächste Intervall-Tick übersprungen, statt eine weitere parallele Anfrage zu starten. Das hält die tatsächliche Anzahl gleichzeitiger Requests unabhängig von der Serverantwortzeit konstant bei maximal eins pro Komponente.

Alpine.data('orderStatusPoller', (orderId) => ({
  status: null,
  intervalId: null,
  inFlight: false,

  init() {
    this.fetchStatus();
    this.intervalId = setInterval(() => this.fetchStatus(), 5000);
  },

  async fetchStatus() {
    if (this.inFlight) {
      return; // vorherige Anfrage läuft noch, diesen Tick überspringen
    }
    this.inFlight = true;

    try {
      const response = await fetch(`/api/orders/${orderId}/status`);
      this.status = await response.json();
    } finally {
      this.inFlight = false;
    }
  },

  destroy() {
    clearInterval(this.intervalId);
  },
}));

4. Exponentielles Backoff bei wiederholten Fehlern

Fällt der Server für einen Moment aus, führt ein starres Fünf-Sekunden-Intervall dazu, dass die Komponente ihn weiterhin im gleichen Takt anfragt, obwohl jede dieser Anfragen fehlschlägt. Bei vielen gleichzeitig geöffneten Tabs verschärft das die Situation für den bereits angeschlagenen Server zusätzlich, statt ihm Zeit zur Erholung zu geben. Exponentielles Backoff begegnet diesem Problem, indem das Intervall nach jedem Fehlschlag verlängert wird, bis zu einer sinnvollen Obergrenze.

Wichtig ist, das Intervall nach dem ersten wieder erfolgreichen Request sofort auf den ursprünglichen Wert zurückzusetzen, damit sich die Komponente nicht dauerhaft in einem langsameren Rhythmus festsetzt, sobald der Server wieder normal antwortet. Ohne diesen Reset würde ein einziger vorübergehender Ausfall die Aktualität der Anzeige auf unbestimmte Zeit verschlechtern.

async fetchStatus() {
  if (this.inFlight) return;
  this.inFlight = true;

  try {
    const response = await fetch(`/api/orders/${this.orderId}/status`);
    if (!response.ok) throw new Error(`Status ${response.status}`);

    this.status = await response.json();
    this.failureCount = 0;
    this.scheduleNext(this.baseInterval);
  } catch (error) {
    this.failureCount++;
    const backoff = Math.min(this.baseInterval * 2 ** this.failureCount, 60000);
    this.scheduleNext(backoff);
  } finally {
    this.inFlight = false;
  }
},

scheduleNext(delay) {
  clearTimeout(this.timeoutId);
  this.timeoutId = setTimeout(() => this.fetchStatus(), delay);
}

5. Polling pausieren, wenn der Tab nicht sichtbar ist

Ein im Hintergrund geöffneter Tab, der weiterhin im normalen Takt pollt, erzeugt Serverlast für eine Anzeige, die aktuell niemand betrachtet. Die Page Visibility API liefert über document.hidden und das visibilitychange-Event genau die Information, die gebraucht wird, um das Polling in diesem Fall gezielt zu pausieren, statt es blind weiterlaufen zu lassen.

Praktisch bedeutet das, im visibilitychange-Handler zwischen dem Anhalten des Intervalls beim Verstecken und dem sofortigen Neustart samt direktem Refresh beim Sichtbarwerden zu unterscheiden. Der sofortige Refresh beim Zurückkehren ist wichtig, damit der Nutzer nicht erst den vollen Intervall abwarten muss, um wieder aktuelle Daten zu sehen, nachdem er länger weg war.

init() {
  this.startPolling();

  this.visibilityHandler = () => {
    if (document.hidden) {
      clearInterval(this.intervalId);
    } else {
      this.fetchStatus(); // sofortiger Refresh beim Zurückkehren
      this.startPolling();
    }
  };

  document.addEventListener('visibilitychange', this.visibilityHandler);
},

startPolling() {
  clearInterval(this.intervalId);
  this.intervalId = setInterval(() => this.fetchStatus(), this.baseInterval);
},

destroy() {
  clearInterval(this.intervalId);
  document.removeEventListener('visibilitychange', this.visibilityHandler);
}

6. Häufige Ursachen für Memory Leaks bei Polling-Komponenten

Neben dem bereits erwähnten fehlenden clearInterval gibt es einen zweiten, ebenso häufigen Fehler: ein registrierter visibilitychange-Listener auf document, der nie wieder entfernt wird. Da document über die Lebensdauer der einzelnen Komponente hinaus bestehen bleibt, hält ein solcher Listener die komplette Komponenten-Closure dauerhaft im Speicher, selbst wenn das zugehörige DOM-Element längst entfernt wurde.

Die Regel lässt sich einfach zusammenfassen: Jeder addEventListener auf einem Objekt, das die Komponente überlebt, wie document oder window, braucht im destroy()-Hook ein passendes removeEventListener mit derselben Funktionsreferenz. Ein anonymes Callback direkt in addEventListener zu übergeben, verhindert später das korrekte Entfernen, weil keine Referenz auf genau diese Funktion mehr existiert.

7. Doppeltes Polling und überlappende Requests vermeiden

Neben dem bereits gezeigten inFlight-Schutz gegen überlappende Anfragen innerhalb einer Komponente lohnt sich ein Blick auf Situationen, in denen dieselbe Komponente versehentlich mehrfach initialisiert wird, etwa durch eine fehlerhafte Alpine.data-Registrierung, die bei jedem Hot-Reload während der Entwicklung ein zusätzliches Intervall anlegt, ohne das alte zu stoppen.

Ein defensiver Ansatz räumt am Anfang von init() vorsichtshalber ein eventuell noch bestehendes altes Intervall auf, bevor ein neues gestartet wird. Das kostet im Normalfall nichts, verhindert aber zuverlässig, dass sich mehrere parallele Polling-Loops für dieselbe Komponente unbemerkt ansammeln.

8. Praxisbeispiel: Ein Bestellstatus-Widget mit adaptivem Intervall

Ein Bestellstatus-Widget nach dem Checkout muss den Status nur so lange abfragen, bis ein Endzustand wie 'versendet' oder 'storniert' erreicht ist, danach ist weiteres Polling reine Verschwendung. Sobald die Komponente einen solchen Endzustand erkennt, sollte sie das Intervall selbst beenden, statt bis zum Entfernen des Elements aus dem DOM weiterzulaufen.

Kombiniert mit der Visibility-Pause und dem exponentiellen Backoff aus den vorherigen Abschnitten entsteht so ein Widget, das nur dann tatsächlich pollt, wenn es sinnvoll ist: sichtbar, mit ausstehendem Status und bei funktionierender Serververbindung. Diese Kombination reduziert die Serverlast eines einzelnen Widgets über die gesamte Nutzungsdauer oft um mehr als die Hälfte im Vergleich zu einem naiven, dauerhaft laufenden Intervall.

9. Das richtige Polling-Intervall wählen

Ein zu kurzes Intervall erzeugt unnötige Serverlast ohne echten Aktualitätsgewinn, ein zu langes Intervall lässt die Anzeige spürbar veraltet wirken. Als Ausgangspunkt hilft die Frage, wie oft sich der zugrunde liegende Wert in der Praxis tatsächlich ändert, und nicht die theoretisch kürzestmögliche Aktualisierungsrate, die technisch machbar wäre.

In vielen Fällen lohnt sich zudem ein adaptives Intervall, das sich am Kontext orientiert: kurz während eines aktiven Checkout-Prozesses, in dem sich der Bestellstatus schnell ändern kann, deutlich länger für ein Dashboard mit historischen Kennzahlen. Die folgende Tabelle stellt die wichtigsten Aspekte eines Polling-Patterns im Vergleich zu den Alternativen aus den vorherigen Artikeln dieser Serie zusammen.

10. Zusammenfassung

11. FAQ: Polling-Pattern mit Alpine.js