# Hoe vervang je polling en webhooks van Replicate Predictions in een bestaande app? > Plaats een providerneutrale asynchrone taakrecord tussen product en API. Laat geverifieerde webhooks of een begrensde polling-worker dezelfde idempotente finalizer bijwerken, normaliseer statussen en kopieer voltooide bestanden naar duurzame opslag. Plaats een providerneutrale taaklaag tussen applicatie en inferentie-API. Normaliseer creatie, status, annulering, voltooiing en opslag zodat het product niet van Replicate-objecten of URL's afhankelijk blijft. Vervang niet alleen een callback-URL. Definieer eerst het vereiste asynchrone contract. ## Documenteer het huidige gedrag Asynchrone creatie bij Replicate levert een prediction-ID, status en hulp-URL's. Apps kunnen `urls.get` pollen, webhook-POST's ontvangen of serverevents gebruiken. Noteer het pad van elke flow en de actie bij elke overgang. | Replicate-concept | Vervanging in de applicatie | |---|---| | Prediction-ID | Provider-taak-ID en interne ID | | `starting`, `processing` | `queued`, `running` | | `succeeded` | `completed` | | `failed`, `canceled` | `failed`, `canceled` | | `urls.get` | Statusmethode van adapter | | Webhook-payload | Genormaliseerd voltooiingsevent | | Uitvoer-URL | Duurzaam applicatie-asset | Bewaar de ruwe providerstatus apart van de genormaliseerde status voor diagnose. ## Introduceer een interne taakrecord Maak de databaseregel vóór de provideroproep: ```json { "job_id": "job_01J...", "provider": "target", "provider_job_id": null, "state": "creating", "attempt": 1, "output_assets": [] } ``` Gebruik de interne `job_id` in interface, queues en meldingen. Voeg de externe ID na creatie toe. Een idempotentiesleutel voorkomt twee betaalde taken na een netwerkfout. ## Vervang polling door een begrensde worker Als het doel taken kan lezen maar geen webhooks biedt, verplaats polling naar een achtergrond-worker. Gebruik exponentiële backoff met jitter, een deadline en maximaal interval. Stop bij elke eindstatus, inclusief annulering. Poll niet vanuit de browser. Een server-worker blijft actief na het sluiten van een tab, centraliseert limieten en slaat overgangen transactioneel op. ## Vervang webhooks door geverifieerde events Houd de handler klein: * verifieer handtekening of geheim vóór parsing; * dedupliceer op event of taak en status; * bevestig snel en zet verwerking in een queue; * haal de officiële taak op bij een gedeeltelijke payload; * accepteer herhaalde en ongeordende bezorging. Replicate filtert start, output, logs en completed. Het doel kan alleen eindsignalen sturen. Verzin geen nauwkeurige voortgang uit schaarse statussen. ## Gebruik één voltooiingspad Polling en webhook roepen dezelfde idempotente finalizer aan. Die vergrendelt de interne taak, bevestigt de externe ID, bewaart de eindstatus, kopieert bestanden naar duurzame opslag en publiceert één event. Zo ontstaan geen dubbele meldingen wanneer webhook en laatste poll tegelijk aankomen. ## Bewaar bestanden voordat ze verdwijnen Replicate documenteert dat in- en uitvoerbestanden van API-predictions na beperkte tijd worden verwijderd. Het doel kan andere bewaring of URL-levensduur gebruiken. Behandel externe URL's als levering, niet als opslag. Download uitvoer snel, valideer type en grootte, scan waar nodig, bewaar onder eigen sleutel en registreer checksums. Geef clients je eigen stabiele URL. ## Test storingen en herstel Test vertraagde creatie, dubbele en gemiste webhooks, 429 en 5xx, annuleringsraces, verlopen URL's, ongeldige payloads en worker-herstart tijdens een taak. Draai beide adapters in shadow mode met veilige input. Vergelijk eindstatussen en assets voordat je een klein deel productie migreert. ## Samenvatting De duurzame vervanging is een intern asynchroon taakcontract, niet verspreide callbacks. Normaliseer statussen, finaliseer idempotent, bewaar bestanden direct en stuur webhook of begrensde worker door hetzelfde voltooiingspad. ## FAQ ### Moet de browser de vervangende API rechtstreeks pollen? Gebruik liever een server-worker. Die blijft draaien na het sluiten van de browser, centraliseert limieten en pogingen en werkt de interne status consistent bij. ### Hoe worden Replicate-statussen gemapt? Map ze naar een kleine interne cyclus zoals creating, queued, running, completed, failed en canceled, en bewaar de ruwe status voor diagnose. ### Hoe voorkom je dubbele webhookverwerking? Verifieer de afzender, dedupliceer op event of op taak en status en stuur webhook en polling naar dezelfde transactionele, idempotente finalizer. ### Wat als de nieuwe provider geen webhooks biedt? Gebruik een achtergrond-worker met exponentiële backoff, jitter, deadline en expliciete afhandeling van alle eindstatussen. ### Kan ik uitvoer-URL's van de provider permanent tonen? Ga niet uit van duurzaamheid. Download uitvoer snel en bied eigen asset-URL's met je eigen toegangscontrole. ### Welke storingen moeten tests afdekken? Test dubbele of gemiste events, limieten, tijdelijke fouten, annuleringsraces, verlopen uitvoer, ongeldige payloads en worker-herstarts.