# Bagaimana Mengganti Polling dan Webhook Replicate Prediction dalam Aplikasi yang Ada? > Tempatkan catatan job asinkron yang netral terhadap penyedia di antara produk dan API. Biarkan webhook terverifikasi atau worker polling terbatas memperbarui finalizer idempoten yang sama, menormalkan status, dan menyalin file selesai ke penyimpanan persisten. Ganti polling dan webhook Replicate dengan lapisan job netral penyedia di antara aplikasi dan API inferensi. Normalkan pembuatan, status, pembatalan, peristiwa selesai, dan penyimpanan output agar produk tidak bergantung pada objek prediction atau URL Replicate. Jangan sekadar mengganti satu callback URL dengan yang lain dalam kode produk. Tentukan dahulu kontrak asinkron yang dibutuhkan aplikasi. ## Catat perilaku saat ini Pembuatan asinkron Replicate mengembalikan ID prediction, status siklus hidup, dan URL praktis. Aplikasi dapat melakukan polling `urls.get`, menerima webhook POST, atau menggunakan server-sent events yang didukung. Catat jalur setiap workflow dan tindakan produk pada tiap transisi. | Konsep Replicate | Pengganti tingkat aplikasi | |---|---| | ID prediction | ID job penyedia plus ID job internal | | `starting`, `processing` | `queued`, `running` | | `succeeded` | `completed` | | `failed`, `canceled` | `failed`, `canceled` | | `urls.get` | Metode status adapter | | Payload webhook | Peristiwa selesai yang dinormalisasi | | URL output | Aset persisten milik aplikasi | Simpan status mentah penyedia terpisah dari status normal. Ini mempertahankan bukti diagnosis saat detail siklus hidup penyedia berbeda. ## Tambahkan catatan job internal Buat baris database sebelum memanggil penyedia baru: ```json { "job_id": "job_01J...", "provider": "target", "provider_job_id": null, "state": "creating", "attempt": 1, "output_assets": [] } ``` Gunakan `job_id` internal di UI, antrean, dan notifikasi. Setelah pembuatan berhasil, pasang ID job penyedia. Kunci idempotensi harus mencegah percobaan ulang jaringan meluncurkan dua job berbayar. ## Ganti polling dengan worker terbatas Jika API target menyediakan pengambilan job tanpa webhook, pindahkan polling ke worker latar belakang. Gunakan exponential backoff dengan jitter, tenggat, dan interval maksimum. Berhenti pada setiap status terminal, termasuk pembatalan. Jangan polling dari browser. Worker server bertahan setelah tab ditutup, memusatkan batas laju, dan menyimpan transisi status secara transaksional. ## Ganti webhook dengan peristiwa terverifikasi Jika target mendukung webhook, buat handler tetap kecil: * verifikasi tanda tangan atau rahasia bersama sebelum parsing; * deduplikasi berdasarkan ID peristiwa atau ID job dan status; * akui dengan cepat lalu antrekan pemrosesan; * ambil job otoritatif jika payload tidak lengkap; * terima pengiriman berulang dan tidak berurutan. Replicate mendukung filter seperti start, output, logs, dan completed. Target mungkin hanya mengirim peristiwa terminal. Buat ulang progres hanya jika bermakna, jangan menciptakan presisi palsu. ## Gunakan satu jalur penyelesaian Polling dan webhook harus memanggil finalizer idempoten yang sama. Finalizer mengunci job internal, memverifikasi ID penyedia, mencatat status terminal, menyalin file output ke penyimpanan persisten, dan memancarkan satu peristiwa aplikasi. Ini mencegah notifikasi ganda saat webhook dan polling terakhir tiba bersamaan. ## Simpan file sebelum hilang Dokumentasi Replicate menyatakan file input dan output prediction API dihapus otomatis setelah periode terbatas. Penyedia baru dapat memiliki retensi atau masa URL bertanda tangan berbeda. Perlakukan URL penyedia sebagai mekanisme pengiriman, bukan penyimpanan permanen. Unduh output sukses segera, validasi jenis dan ukuran, pindai bila perlu, simpan dengan kunci aplikasi, dan catat checksum. Sajikan URL aset stabil milik Anda. ## Uji kegagalan dan pemulihan Uji respons pembuatan tertunda, webhook duplikat atau hilang, respons polling 429 dan 5xx, race pembatalan, URL kedaluwarsa, payload rusak, dan restart worker di tengah job. Jalankan kedua adapter dalam mode shadow untuk input aman. Bandingkan status terminal dan jumlah aset sebelum memindahkan trafik produksi secara canary. ## Intinya Pengganti polling dan webhook Replicate yang tahan lama adalah kontrak job asinkron internal, bukan callback khusus penyedia yang tersebar. Normalkan status, buat finalisasi idempoten, simpan file segera, dan arahkan webhook terverifikasi atau worker terbatas ke jalur penyelesaian yang sama. ## FAQ ### Haruskah browser melakukan polling API pengganti secara langsung? Gunakan worker sisi server. Worker tetap berjalan setelah browser ditutup, memusatkan batas laju dan percobaan ulang, serta memperbarui status internal secara konsisten. ### Bagaimana memetakan status prediction Replicate? Petakan ke siklus hidup internal kecil seperti creating, queued, running, completed, failed, dan canceled sambil menyimpan status mentah untuk diagnosis. ### Bagaimana mencegah webhook diproses dua kali? Verifikasi sumber, deduplikasi berdasarkan peristiwa atau ID job dan status, lalu arahkan webhook dan polling ke finalizer transaksional yang idempoten. ### Bagaimana jika penyedia baru tidak memiliki webhook? Gunakan worker latar belakang dengan exponential backoff, jitter, tenggat, dan penanganan eksplisit untuk semua status terminal. ### Bisakah URL keluaran penyedia ditampilkan secara permanen? Jangan menganggapnya persisten. Unduh keluaran segera dan sajikan URL aset aplikasi dengan kontrol akses Anda sendiri. ### Kegagalan apa yang harus diuji? Uji peristiwa duplikat atau hilang, pembatasan laju, kesalahan sementara, race pembatalan, keluaran kedaluwarsa, payload rusak, dan restart worker.