# Jak zastąpić odpytywanie i webhooki Replicate Predictions w istniejącej aplikacji? > Umieść niezależny od dostawcy rekord zadania asynchronicznego między produktem a API. Skieruj zweryfikowane webhooki i ograniczony worker odpytywania do tego samego idempotentnego finalizatora, ujednolić stany i kopiuj gotowe pliki do trwałego magazynu. Umieść neutralną warstwę zadań między aplikacją a API. Normalizuj tworzenie, stan, anulowanie, zdarzenia ukończenia i zapis wyników, aby produkt nie zależał od obiektów i URL Replicate. Nie zmieniaj tylko callback URL. Najpierw zdefiniuj potrzebny kontrakt asynchroniczny. ## Udokumentuj obecne zachowanie Asynchroniczne tworzenie Replicate zwraca ID prediction, stan i pomocnicze URL. Aplikacja może odpytywać `urls.get`, odbierać POST webhook lub używać zdarzeń serwera. Zapisz ścieżkę każdego procesu i działanie przy każdej zmianie. | Pojęcie Replicate | Zamiennik w aplikacji | |---|---| | ID prediction | ID zadania dostawcy i ID wewnętrzny | | `starting`, `processing` | `queued`, `running` | | `succeeded` | `completed` | | `failed`, `canceled` | `failed`, `canceled` | | `urls.get` | Metoda stanu adaptera | | Ładunek webhook | Znormalizowane zdarzenie ukończenia | | URL wyniku | Trwały zasób aplikacji | Surowy stan dostawcy przechowuj osobno od znormalizowanego, aby diagnozować różnice cyklu życia. ## Wprowadź wewnętrzny rekord zadania Utwórz wiersz bazy przed wywołaniem nowego dostawcy: ```json { "job_id": "job_01J...", "provider": "target", "provider_job_id": null, "state": "creating", "attempt": 1, "output_assets": [] } ``` Używaj wewnętrznego `job_id` w interfejsie, kolejkach i powiadomieniach. Zewnętrzny ID dodaj po utworzeniu. Klucz idempotencji zapobiega dwóm płatnym zadaniom po błędzie sieci. ## Zastąp odpytywanie ograniczonym workerem Jeśli cel pozwala czytać zadania, ale nie ma webhooków, przenieś odpytywanie do workera. Użyj wykładniczego opóźnienia z jitterem, terminu i maksymalnego interwału. Zatrzymaj się przy każdym stanie końcowym, także anulowaniu. Nie odpytuj z przeglądarki. Worker serwera działa po zamknięciu karty, centralizuje limity i transakcyjnie zapisuje przejścia. ## Zastąp webhooki zweryfikowanymi zdarzeniami Utrzymuj mały handler: * sprawdzaj podpis lub sekret przed analizą; * deduplikuj po zdarzeniu albo zadaniu i stanie; * szybko potwierdzaj i kolejkuj przetwarzanie; * przy częściowym ładunku pobierz oficjalne zadanie; * akceptuj powtórzoną i nieuporządkowaną dostawę. Replicate filtruje start, output, logs i completed. Cel może wysyłać tylko zdarzenia końcowe. Nie twórz fałszywej precyzji postępu. ## Użyj jednej ścieżki ukończenia Odpytywanie i webhook wywołują ten sam idempotentny finalizator. Blokuje rekord, potwierdza zewnętrzny ID, zapisuje stan końcowy, kopiuje pliki do trwałego magazynu i emituje jedno zdarzenie. Dzięki temu jednoczesny webhook i ostatni odczyt nie powodują podwójnych powiadomień. ## Zachowaj pliki przed zniknięciem Replicate informuje, że pliki wejścia i wyjścia prediction API są usuwane po ograniczonym czasie. Cel może mieć inną retencję lub żywotność URL. Traktuj zewnętrzny URL jako dostawę, nie magazyn. Szybko pobieraj wyniki, sprawdzaj typ i rozmiar, w razie potrzeby skanuj, zapisuj pod własnym kluczem i notuj sumy kontrolne. Klientom dawaj własny stabilny URL. ## Testuj awarie i odzyskiwanie Testuj opóźnione tworzenie, podwójne i brakujące webhooki, 429 i 5xx, wyścigi anulowania, wygasłe URL, błędne ładunki i restart workera podczas zadania. Uruchom oba adaptery w trybie cienia z bezpiecznym wejściem. Porównaj stany końcowe i zasoby przed małym canary produkcyjnym. ## Podsumowanie Trwałym zamiennikiem jest wewnętrzny kontrakt zadania asynchronicznego, nie rozproszone callbacki. Normalizuj stany, finalizuj idempotentnie, szybko zachowuj pliki i prowadź webhook lub ograniczony worker tą samą ścieżką ukończenia. ## FAQ ### Czy przeglądarka powinna bezpośrednio odpytywać nowe API? Lepiej użyć workera po stronie serwera. Działa po zamknięciu przeglądarki, centralizuje limity i ponowienia oraz spójnie aktualizuje stan wewnętrzny. ### Jak mapować stany prediction w Replicate? Mapuj je na mały cykl wewnętrzny, taki jak creating, queued, running, completed, failed i canceled, zachowując stan surowy do diagnostyki. ### Jak uniknąć podwójnego przetwarzania webhooka? Weryfikuj autentyczność, usuwaj duplikaty według zdarzenia albo zadania i stanu oraz kieruj webhook i odpytywanie do jednego transakcyjnego finalizatora. ### Co zrobić, gdy nowy dostawca nie ma webhooków? Użyj workera w tle z wykładniczym opóźnieniem, jitterem, terminem i jawną obsługą wszystkich stanów końcowych. ### Czy można stale pokazywać adresy wyników dostawcy? Nie zakładaj trwałości. Szybko pobieraj wyniki i udostępniaj własne adresy zasobów z własną kontrolą dostępu. ### Jakie awarie powinny obejmować testy? Testuj zdarzenia podwójne i brakujące, limity, błędy przejściowe, wyścigi anulowania, wygasłe wyniki, nieprawidłowe ładunki i restart workera.