# Wie ersetzt man Replicate-Prediction-Polling und Webhooks in einer bestehenden Anwendung? > Setzen Sie einen anbieterneutralen asynchronen Auftragsdatensatz zwischen Produkt und API. Lassen Sie verifizierte Webhooks oder einen begrenzten Polling-Worker denselben idempotenten Finalizer aktualisieren, vereinheitlichen Sie Status und kopieren Sie fertige Dateien in dauerhaften Speicher. Setzen Sie eine anbieterneutrale Auftragsschicht zwischen Anwendung und Inferenz-API. Vereinheitlichen Sie Erstellung, Status, Abbruch, Abschlussereignisse und Ausgabeaufbewahrung, damit das Produkt nicht von Replicate-Objekten oder URLs abhängt. Tauschen Sie nicht nur eine Callback-URL aus. Definieren Sie zuerst den benötigten asynchronen Vertrag. ## Aktuelles Verhalten dokumentieren Die asynchrone Replicate-Erstellung liefert Prediction-ID, Status und Hilfs-URLs. Anwendungen können `urls.get` abfragen, Webhook-POSTs empfangen oder Server-Sent Events nutzen. Erfassen Sie den Weg jedes Ablaufs und die Aktion bei jedem Übergang. | Replicate-Konzept | Ersatz in der Anwendung | |---|---| | Prediction-ID | Anbieter-Auftrags-ID und interne ID | | `starting`, `processing` | `queued`, `running` | | `succeeded` | `completed` | | `failed`, `canceled` | `failed`, `canceled` | | `urls.get` | Statusmethode des Adapters | | Webhook-Nutzlast | Normalisiertes Abschlussereignis | | Ausgabe-URL | Dauerhaftes Anwendungs-Asset | Speichern Sie den Rohstatus getrennt vom normalisierten Status, um Unterschiede diagnostizieren zu können. ## Einen internen Auftrag einführen Erstellen Sie den Datenbankeintrag vor dem Aufruf des neuen Anbieters: ```json { "job_id": "job_01J...", "provider": "target", "provider_job_id": null, "state": "creating", "attempt": 1, "output_assets": [] } ``` Verwenden Sie die interne `job_id` in Oberfläche, Warteschlangen und Benachrichtigungen. Ergänzen Sie die externe ID nach der Erstellung. Ein Idempotenzschlüssel verhindert doppelte kostenpflichtige Aufträge. ## Polling durch einen begrenzten Worker ersetzen Wenn das Ziel Aufträge abrufen kann, aber keine Webhooks bietet, verlagern Sie Polling in einen Hintergrund-Worker. Nutzen Sie exponentielles Backoff mit Jitter, Frist und Maximalintervall. Stoppen Sie bei jedem Endstatus einschließlich Abbruch. Pollen Sie nicht im Browser. Ein Server-Worker überlebt das Schließen des Tabs, bündelt Limits und speichert Zustandswechsel transaktional. ## Webhooks durch verifizierte Ereignisse ersetzen Halten Sie den Handler klein: * Signatur oder gemeinsames Geheimnis vor dem Parsen prüfen. * Nach Ereignis-ID oder Auftrag und Status deduplizieren. * Schnell bestätigen und Verarbeitung einreihen. * Bei Teildaten den offiziellen Auftrag abrufen. * Wiederholte und ungeordnete Zustellung erlauben. Replicate filtert start, output, logs und completed. Ein Ziel kann nur Endereignisse senden. Erfinden Sie keine präzise Fortschrittsanzeige aus wenigen Status. ## Einen Abschlussweg verwenden Polling und Webhook rufen denselben idempotenten Finalizer auf. Er sperrt den internen Auftrag, bestätigt die externe ID, speichert den Endstatus, kopiert Dateien in dauerhaften Speicher und sendet genau ein Ereignis. So entstehen keine doppelten Benachrichtigungen, wenn Webhook und letzte Abfrage gemeinsam eintreffen. ## Dateien vor dem Verschwinden sichern Replicate dokumentiert, dass Ein- und Ausgabedateien von API-Predictions nach begrenzter Zeit gelöscht werden. Das Ziel kann eine andere Aufbewahrung oder URL-Laufzeit haben. Behandeln Sie externe URLs als Lieferweg, nicht als Speicher. Laden Sie Ausgaben umgehend, prüfen Sie Typ und Größe, scannen Sie sie bei Bedarf, speichern Sie sie unter eigenen Schlüsseln und protokollieren Sie Prüfsummen. Geben Sie eigene stabile URLs aus. ## Fehler und Wiederherstellung testen Testen Sie verspätete Erstellung, doppelte und fehlende Webhooks, 429 und 5xx, Abbruchrennen, abgelaufene URLs, ungültige Nutzlasten und Worker-Neustarts während eines Auftrags. Führen Sie beide Adapter mit sicheren Eingaben im Schattenbetrieb aus und vergleichen Sie Endstatus und Assetzahlen vor einem kleinen Produktions-Canary. ## Fazit Der dauerhafte Ersatz ist ein interner asynchroner Auftragsvertrag statt verteilter Anbieter-Callbacks. Vereinheitlichen Sie Status, finalisieren Sie idempotent, sichern Sie Dateien sofort und führen Sie Webhooks oder begrenztes Polling in denselben Abschlussweg. ## FAQ ### Soll der Browser die Ersatz-API direkt abfragen? Nutzen Sie besser einen serverseitigen Worker. Er überlebt das Schließen des Browsers, bündelt Limits und Wiederholungen und aktualisiert den internen Status konsistent. ### Wie werden Replicate-Prediction-Status abgebildet? Bilden Sie sie auf einen kleinen internen Lebenszyklus wie creating, queued, running, completed, failed und canceled ab und bewahren Sie den Rohstatus zur Diagnose auf. ### Wie verhindert man doppelte Webhook-Verarbeitung? Prüfen Sie die Echtheit, deduplizieren Sie nach Ereignis oder Auftrag und Status und führen Sie Webhook und Polling in denselben transaktionalen, idempotenten Finalizer. ### Was ist zu tun, wenn der neue Anbieter keine Webhooks bietet? Verwenden Sie einen Hintergrund-Worker mit exponentiellem Backoff, Jitter, Frist und expliziter Behandlung aller Endstatus. ### Darf ich Ausgabe-URLs des Anbieters dauerhaft anzeigen? Gehen Sie nicht von Dauerhaftigkeit aus. Laden Sie Ausgaben zügig herunter und stellen Sie eigene Asset-URLs mit Ihrer Zugriffskontrolle bereit. ### Welche Fehler sollten Migrationstests abdecken? Testen Sie doppelte oder fehlende Ereignisse, Limits, vorübergehende Fehler, Abbruchrennen, abgelaufene Ausgaben, ungültige Nutzlasten und Worker-Neustarts.